Ben Collins-Sussman <sussman@collab.net> writes:
> * Proposed Action Plan
>
> 1. Cleanup of loose ends.
> (Can't yet estimate how long this will take.)
>
> - Look at issuetracker, decide which open issues (if any)
> should considered 1.1 "showstoppers". Fix them ASAP. Fan
> out remaining issues from 1.1 to other 1.X releases.
>
> - Allow any other code-cleanups in process to come to a
> good stopping point.
>
> 2. Copy /trunk to /branches/1.1.x and release a 1.1-beta1 tarball.
> (This procedure is described in the HACKING file, take a look.)
>
> 3. Allow the 1.1 branch and 1.1-beta1 tarball to "soak" for four
> weeks. If necessary, release subsequent beta tarballs duing
> this time. (Again, this is all described in HACKING.)
Ben, we had this discussion on the phone, but I wanted to rehash it
publicly.
My only concern with cutting 1.1 early (and delaying locking for 1.2)
was that it means we now have three lines of development to maintain (and
then four when 1.2 is done). That would mean fixing bugs on trunk and
then doing two (then three) backports. Many releases, etc.
Maintenance nightmare.
But as we agreed, perhaps because of the binary compatibility rules,
it's safe to halt work on the 1.0.x line the minute that 1.1 is
released. If a critical bug in 1.0.x, we can fix it in trunk and
backport to 1.1.x, and tell 1.0.x users to upgrade to 1.1.x. Of
course, this only holds so long as the upgrade from 1.0.x to 1.1.x is
painless and comes at no additional cost to users.
Are we understanding the version numbering scheme right? Is this an
acceptable plan of attack?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 7 19:09:07 2004