Greg Hudson <ghudson@MIT.EDU> writes:
> In http://www.contactor.se/~dast/svn/archive-2003-10/0128.shtml
> you proposed the same plan, but later appeared to concede that you were
> happy to stabilize on the trunk. I continue to favor stabilizing on the
> trunk; otherwise, we run the risk of having a long beta period where the
> stable branch diverges dramatically from the trunk, and our resources
> are divided between them.
Yes, I originally hoped we could do it all from trunk. (Sorry, I
should have referred to that earlier mail and said explicitly that I
was contradicting it. Due to travel constraints, I have a very slow
box at the moment, which is discouraging me from doing such extra
digging.)
Two things made me think again that we should use a branch:
First, I talked to some people who've had more experience managing
software releases (Jack Repenning and Greg Stein among others), and
they made the point that it's a lot easier to set termination
conditions for a branch. The branch gives the release manager more
freedom to make stabilization decisions. For example, there have been
a whole lot of medium-impact commits in the last few weeks on trunk.
If this trend continues, we would face a choice between discouraging
people from doing that work, or having lots of code churn just when
we're trying to stabilize for release.
The other thing was the realization that, if we're going to be
maintaining a stable line anyway, isolated from new feature
development, then we might as well start that line before the release.
The stability discipline isn't something you want to impose right
*after* 1.0 comes out, but rather before.
> > This is essentially the "even==stable, odd==dev" scheme that many
> > other projects use.
>
> ... which is confusing as hell to the uninitiated. -0.9 on such a
> numbering scheme.
It sounds like the fundamental question here is: are we going to
maintain a separate stable line or not?
I think we should. Not everyone wants or needs the bleeding edge all
the time, yet others do need the latest development code. I think
it's not by accident that so many widely-used projects have solved
this the same way.
If you think a separate stable line is a good idea, then the rest is
details. If you don't like the even/odd thing, I'm all ears for a
better scheme. I considered others, some of which included the words
"dev" and "stable" in the release names themselves. Eventually I
ended up back at the even/odd system, but maybe there's some really
good solution I just didn't think of. There is an inherent complexity
in maintaining separate stable and dev lines, though, and we can't
entirely paper over that.
If, on the other hand, you don't think we should maintain separate and
dev lines after each major release (such as 1.0), then let's talk
about that, as it's the real issue here.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 4 20:02:37 2003