This is the first of two mails. This one deals with how to treat the
0.37/1.0 line between now and the 1.0.0 release, and how to treat the
1.0.x line after that release.
The second mail will be about the larger Post-1.0 universe -- about
achieving consensus on what should go into 1.x versus 2.0. (The
second mail will also talk about release numbering, but I need to go
carefully back over our long thread on that before making a serious
proposal.)
Needless to say, this first mail is the simpler of the two :-).
Everything below is merely one proposal, just how I envision the
process working. Although written in declarative tone for clarity,
I'm not trying to present it as the only possible path. Feedback
(negative or positive) is welcome.
Release 0.37.0 is our first "1.0 candidate" release, meaning that
barring the discovery of serious bugs, it is what we will release as
1.0. We should aim to have four weeks of "soak time" for this code,
so we can be confident it contains no surprises.
Note that I said "surprises", not "bugs" :-). We should assume we'll
find *some* bugs in 0.37.0, the question is only how serious will they
be. We should evaluate them on a case-by-case basis. If a bug is
deemed acceptable for the 1.0 release (and I expect/hope most will
be), we can treat it like any other bug: file an issue, maybe fix it
in trunk right then if we want.
Of course, there will be some fixes that we feel should eventually get
into the 1.0.x line, just not into 1.0.0. (I'm punting on the release
numbering question for the moment -- for the sake of discussion, let's
talk as though "1.0.0", "1.0.1", and "1.0.2", are successive public
releases on the stable 1.0 line.) To keep track of such changes,
let's use the STATUS file as before. Since 1.0.x is supposed to be a
stable, ABI-compatible line, let's also use the same voting system
there, for as long as the line lasts.
However, for a clear lineage from 0.37.0->1.0, what I'd like to do is:
1. Remove the 1.0-stabilization branch, which has had no changes
since r8509, when josander branched 0.37.0.
2. Create branches/1.0.0, copied from the 0.37.0 tag.
3. Accept certain kinds of innocuous commits in the 1.0.0 branch for
the next four weeks [details below], including STATUS commits.
An "innocuous commit" is one that doesn't affect our four-week
soak time.
4. When Feb. 23rd arrives, josander rolls subversion-1.0.0.tar.gz
from the 1.0.0 branch, tags it, and goes contentedly to bed :-).
Obviously, no core code change is innocuous. But these kinds of
changes are:
* Any documentation changes, including book changes, INSTALL,
HACKING, www/ area, etc. (The www/ area we can just update all
at once from trunk on the day of the release, if we want.)
* Any dist.sh changes josander wants.
* STATUS file updates, such as inserting 1.0.1 candidate changes.
I think the above categories don't even need voting, let's just treat
them like trunk commits, with post-facto review. Meanwhile, the
categories below would use the voting system, but still not affect the
soak time:
* Anything in tools/, packages/.
* Bindings-only changes. (I'm hoping there aren't any more 1.0
bindings changes left, but if there are, it's more important to
ship with the latest bindings than to soak the bindings for a
whole month.)
* Doc fixes in core code header files or source files.
If we do find a showstopper bug in 0.37.0, then we release 0.37.1 as
per usual procedures, then run the above algorithm with "0.37.1"
substituted for "0.37.0". In which case, the four-week countdown
would start from 0.37.1's release date, not 0.37.0's, of course.
That's all. Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 26 18:58:01 2004