William A. Rowe, Jr. wrote:
From discussion - I see us branching 2.1.x anyways, but still object since we will now be maintaining two or three backports for every bugfix commit to trunk/.
If the trees are so in sync that the same patch applies it's trivial to do the backports.
Humbly suggest this isn't the conclusion we reached at AC Las Vegas, and suggest it's still the wrong solution to a non-problem.
If there was a 2.1.x beta out there right now I would agree it was a non-problem. It would be a good thing to restate what the conclusions were at AC 2004 US.
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.
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.
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.
Sander
