I fully agree with you, David. On Thu, 2002-04-25 at 22:14, David Chart wrote: > 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 -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Ghandi + So let's do it...?
signature.asc
Description: This is a digitally signed message part
