First, +1 on releasing 1.1 with what we have.
Regarding the N lines of development/maintenance thing:
"C. Michael Pilato" <cmpilato@collab.net> writes:
> 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?
I think so, basically. But let's not declare 1.0.x defunct
immediately on releasing 1.1; instead, give 1.1 a bit of seasoning
time first.
There will be some very conservative repositories that don't want to
upgrade even to 1.1 until it's seasoned (on average, these will also
be the largest and most prominent repositories). Yet, if there's a
security patch or something, those repositories do need a clear
upgrade path. So even if the upgrade to 1.1 is administratively
painless, that wouldn't mean we want to make it the only option right
away. Of course, we're not obligated to support arbitrary degrees of
conservativism, but in this case, I think we'd be wise to support
*some* degree.
Around the time of 1.1.1 or 1.2, whichever comes earlier, we can
declare the 1.0.x line defunct. I'm just saying, let's not rush it.
Also, we can be as restrictive as we want with what goes into 1.0.x
after 1.1 comes out -- it's fine to limit it to security patches and
huge bug fixes only. There won't be many of those.
-Karl
---------------------------------------------------------------------
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:27:57 2004