On Thu, 2003-12-04 at 13:15, kfogel@collab.net wrote:
> First, I talked to some people who've had more experience managing
> software releases (Jack Repenning and Greg Stein among others)
I have seven years of job experience as a release engineer, if we're
using personal qualifications as a means of justification.
> 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.
This kind of reasoning works when you're looking at stabilizing a
release for 2-6 weeks. When you're stabilizing for six months, you
really have to do that on the trunk. I've seen this go bad; too many
developers stick with the trunk and the release doesn't get enough
attention, or (less likely) too many developers stick with the release
branch and the trunk festers with changes whose brokenness isn't
exposed.
After we go into beta, we should discourage people from making
medium-impact changes between then and release-candidate time, unless
they can justify that the change must go into 1.0. People can make
feature branches if they must.
After the 1.0 release, it hopefully won't require anything like six
months of stabilization for future releases, so this will be less of an
issue. (And if it is an issue, then we can slow down development on the
trunk just as I'm proposing we do now.)
> > > 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?
Uh, that is a fundamental question, yes, but it has nothing to do with
even==stable, odd=dev.
> 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.
Nothing's going to be perfect, but I don't consider it acceptable to
have a version number like "1.1.6" and the user is just supposed to know
that that's not a real, stable release because the middle number is odd.
I think we should strongly consider the option of, after 1.0, not
putting out version-numbered-releases which aren't part of a stable
branch. So we can have "1.1 beta 1" or "1.1rc1" for pre-releases, and
"1.1.1" for releases, but we can't have "post-1.1 version 10" for
something on the trunk which happens to postdate the 1.1 branchpoint.
If we do want to release tarballs from the trunk, we call them
"snapshots" and label them by revision number
(svn-snapshot-r9866.tar.gz).
---------------------------------------------------------------------
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:37:59 2003