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
