Greg Hudson <ghudson@MIT.EDU> writes:
> > 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.
Well, yes, it does make a difference for me anyway. This is one of
those areas where experience counts for a lot. (When I wrote "more
experience", I meant more than me.)
> 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.)
Ah, I think we have some mismatched assumptions here.
IMHO we are looking at weeks, not months, for this stabilization
branch. Maybe not 2-6 weeks, but probably 4-8 weeks. We don't get a
lot of showstopper issues anymore; we have the occasional null pointer
brainos and such, but not core design issues (not for pre-1.0 anyway).
I'd be totally shocked if we needed 6 months to stabilize, based on
the state of Subversion today.
I think it's okay for developer attention to be mostly focused on the
trunk. The release branch doesn't need developer attention so much as
it needs user exposure -- that's why we'd make interim releases only
from the branch. (Developers will still build and test trunk, of
course, so it won't be completely unexercised during this time.)
So the penalty of having this branch may not be as high as you think.
However, If other developers are as ready as you to focus mainly on
1.0-stabilization, then I guess we could forego the branch and just do
it in trunk. We do need to make a clean partition between
stabilization and ongoing development at some point; whether that
partition starts slightly before the 1.0 release, or just at the 1.0
release, is less important, I suppose.
Regarding that other topic, numbering schemes:
Some people have suggested a modified version of the "odd==dev,
even==stable" scheme whereby the dev releases actually get the word
"-dev" in their name, so it's obvious that they're bleeding edge.
(The stable releases don't need a corresponding "stable" in their
name, because you don't need to warn someone that they're about to
install stable software.)
Thus we'd have a stable maintenance line like this
subversion-1.0.0.tar.gz
subversion-1.0.1.tar.gz
subversion-1.0.2.tar.gz
And development releases like this:
subversion-1.1.0-dev.tar.gz
subversion-1.1.1-dev.tar.gz
subversion-1.1.2-dev.tar.gz
This rocks, +1, etc, I only wish I'd proposed it in my original mail :-).
Would this method alleviate your concerns about having clearly
labelled releases, Greg (Hudson)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 5 01:55:17 2003