Re: Releasing 1.6

Stefan Sperling wrote:
> On Thu, Aug 07, 2008 at 01:21:40PM -0400, C. Michael Pilato wrote:
>> Karl Fogel wrote:
>>> So I guess I'm sort of surprised that we're having trouble agreeing to
>>> such a low-risk, high-(potential)-payoff experiment...
>> To quote Mark: "What he said"
>
> Good morning everyone,
>
> After reading everything which has accumulated over night
> in this thread (from the point of view of my timezone), I get the
> impression that the following are the options being discussed:
>
> 1). Let Mark, Senthil and whoever wants to join their effort
> create a feature-branch based on 1.5.x. Complete work on the
> desired features in trunk and backport them to this branch.
> The backport of the desired features happens in our public
> repository.
>
> To prevent version confusion among our users, vendors are
> asked to ship binaries compiled from this branch to the general
> public only if they are explicitly designated as not being based
> on the official Subversion-1.5.x code, because they contain
> features not present in stock 1.5.x.
>
> Users of the feature branch are effectively acting as
> beta-testers for the new features before they officially
> ship in 1.6 at the end of this year.
>
> 2). Complete the desired features in trunk and ship 1.6 early,
> partly in order to avoid version confusion among users caused by
> binaries compiled from the feature-branch, and partly to get the
> desired features out to all of our users and not just users of
> the feature-branch.
>
> There is no beta-testing except for the soak period.
>
> Only binaries based on officially blessed 1.6 code are shipped.
> Confusion about different versions among users is avoided.
>
> Everything happens in our public repository.
>
> 3). Don't do any of the above, and let Mark, Senthil and whoever
> wants to join their effort manage a patched Subversion 1.5
> in private. Release 1.6 as originally planned.
>
> It seems no one wants option 3.
>
> Mark, Karl, Lieven, Arfrever and Michael said they favour option 1.
>
> Justin seems to favour option 2, but also said that one of the
> problems he'd see with option 1 would be vendors shipping binaries
> designated as "Subversion 1.5" from the feature branch. It seems
> that virtually everyone agrees that this is an issue, so I made
> this condition part of option 1 above.
> The other issue with option 1 being that it makes the features
> available early only to users of the feature branch until 1.6 is
> released.
>
> Martin Furter and Peter also expressed agreement with option 2.
>
> Blair is against option 2 because he wants to use the time until
> 1.6 release to complete file externals work.
>
> I myself am -1 on option 3, +0 on option 2 and +1 on option 1.
>
> I think option 1 is the most reasonable option because:
>
> - Nobody is forced to help working on the feature-branch.
> People who don't want to work on it can just ignore it.
> OTOH, if we released 1.6 now, many of us would probably be
> inclined to help with release stabilisation, taking time
> away from other things.
>
> - The features will be shipped to all users in 1.6 anyway.
> 1.6 is scheduled to be released in about 4 months,
> this is not a very long time.
>
> - I think the features receiving beta testing in a real environment
> is a good thing, because there may still be bugs lurking here and
> there (some known, e.g. issue #3226). Anyone who wants to help beta
> testing the features can compile their own builds from the feature
> branch (or trunk, for that matter, but that is probably less safe
> in production environments).
>
> - It also gives people time to complete work they'd like to see in
> 1.6 as planned. I'd like to fix issue #3226, Blair would like to
> finish file externals, Arfrever would like a bunch of features to
> be ready. And I don't think this implies that anyone would block
> the 1.6 release as originally scheduled, even if some feature isn't
> ready by then. We've learned our release-disaster lessons, right? ;)

Stefan,
Thanks for distilling the relevant points into a cohesive email. I think you've
captured the kernel of what is going on here.

Mark, et. al., go ahead and create the branch.

After all, it's under version control. You can't screw up the repository, and
should something go terribly wrong, we can always revert the changes. Having
the work done in public is much better than private. If we need to discuss
something (release naming, etc.) later on, fine. At least we'll have concrete
examples upon which to base the discussion, not the ethereal straw men we're
dealing with today.

-Hyrum