From: David Chart (linux@dchart.demon.co.uk)
Date: Thu Apr 25 2002 - 17:14:13 EDT
On Thu, 2002-04-25 at 18:28, Mike Nordell wrote:
> Paul Rohr wrote:
> > Discovering bad bugs at step 3 is a clear indicator that the release was
> > *not*, in fact, ready for prime time.
>
> Indeed. Would it be feasible to create a "test" release before major
> releases? It would obviously be a greater burden for all, and it would
> probably create "test2" and so on releases, but it would probably iron out
> the "obvious" bugs.
>
> Since I really don't know how much effort goes into a full release-cycle
> it's possible this idea is in reality not possible.
>
I think the release process itself has, in the past, been far too quick.
For the 0.99, 0.9, and 0.7 series, I don't think this was a serious
problem. They were *supposed* to be development releases. Serious bugs
were to be expected. For the 1.0 series, however, I think we need to
slow down a bit.
So, I suggest the following:
1) One of the core developers decides it's time to tag a release, just
as happens now. Consensus is built, and it happens.
2) CVS is branched as 1.0.xrc1. New commits do not go into the release
branch.
3) People test the release candidate. They make sure they can build
binaries on their systems, and that they can do normal stuff. A standard
test suite would be good, an automated standard test suite even better.
Allow about a week for this.
4) If there are any showstopper bugs in rc, fix them and check the fixes
into the branch. Nothing else goes into the branch. Not even dead simple
fixes for other bugs. rcn+1 is tagged in the branch. Return to step 3.
5) If there are no showstopper bugs, the branch gets retagged as 1.0.x,
and the release is announced. All the binaries already exist, so we can
release quickly. Since a week has passed since the last commit was made,
the Changelog is up to date. (I get time to do it at least once a week
under normal circumstances.)
This, of course, needs a definition of showstopper. Suggestions:
a) Doesn't build dist. Obviously.
b) Crash on core function. Opening a standard .abw document, for
example. We'd need a list of these in the test suite.
c) Dataloss on core function. The bug in, er, 0.99.2 or so which
resulted in all style information being lost on save would be an
example.
I think that, most of the time, rc1 would end up being the release,
since most past releases have met this standard. About 25% of the time,
there'd be an rc2, but Abi's generally pretty solid, so I wouldn't
expect rc3 to be very common.
This might also give me time to write proper release notes, rather than
just updating the changelog.
Comments?
-- David Chart
This archive was generated by hypermail 2.1.4 : Thu Apr 25 2002 - 17:15:47 EDT