At 05:26 PM 5/2/2005, Sander Striker wrote: >>Bill makes some good points... it seems that branching would simply be >>"renaming" trunk. The good thing is that with svn this is cheap >>and easy, but will it really do what we want? Also, the "gotta >>backport this to yet another branch" issue is valid. > >No it isn't. That's the whole point of stabilizing. No more >worries about whether someone actually reviewed the slew of changes >the night before the RM intended to tag.
Tag, fix, retag, fix, and bless. Once the candidate is 99% of where the beta should be, such cosmetics are trivial. >The backport issue will still stay FWIW. If not now, it will come >at the time we have 2.0 and 2.2 out there, and trunk is at 2.3-dev. >It's not like we can drop support for 2.0 then. Not so much ... Do we all believe that after 2.2 is "Released", there will be much activity on 2.0, other than closing security holes? Unlike 1.3 -> 2.0 - the migration to 2.2 is relatively straightforward. Not entirely, because we break binary compatibility, and users will have some lag before everything just works and all 3rd party binary modules become available. That said; if you want a "BETTER" Apache, installing 2.2 will become the stock answer. We couldn't expect that of 1.3 users in the same, simple way we can encourage 2.0 users. Obviously 1.3 and 2.0 were night and day. >>In other words, trunk is 2.1 anyway, so what does a branch provide? >>I would say it's a perception advantage mostly. > >Well, it would let people continue to have a place where they can >develop the larger features/refactoring jobs. That's indeed only >a handful of people, but at the same time a group of people who >do a lot of work. Larger features/Refactoring belong pre-committed to a sandbox or work branch. That's been true since before most of our time. Bill
