On Mon, Jun 08, 1998 at 01:22:26PM +0100, Ian Jackson wrote: > We must decouple our development tracks much more. I propose that we > resolve never again to plan a release with is not fully backward > compatible with the current stable version. Agreed! Those of us who have been talking about possible suggestions for changing the way releases are handled all seem to agree that changes should be phased in. > We should abandon the idea of `release goals'. Instead, if someone > thinks a thing definitely needs doing by the time of a release, they > do it. If it doesn't get done then we release anyway. I don't see anything MAJOR in the plans for 2.1 that could not be done this way. It seems though like a good plan. > So, in detail: > > Every three months (fixed date) we copy the current `unstable' into > `frozen'. At this point `stable', `frozen' and `unstable' should all > stay interoperable both in source and binary form. This still doesn't address the problem of packages that really aren't ready to be released. That's kinda why we were suggesting unstable be a pool for packages in development. If they're ready for release, move them to frozen. That way nobody's package is being "left out" of a dist because of a bug, but rather being moved into a release after a fair amount of time if the package is ready in the author's opinions. (I was suggesting the bug system be used as part of that since the authors have control over the priority of the bugs against their packages) > Bugfixes must be applied to frozen, and important ones to stable too. > After one or two months of beta frozen should be stable enough to > release. Is this not how things are done wrt frozen and to stable now? > If it's not fine with you then let's not hold up the releases - > instead, go and fix those packages. This is the biggest reason for Guy and co's suggestion about making unstable a pool in which packages start and move out of--so no package can hold up a release. If the author believes the current version of a package is not yet stable enough for release, the last stable version would be used. This requires that we don't break backward compatibility, but for all the other reasons we had before we should keep things as compatible as possible anyway.
Attachment:
pgpxluQvUFGFg.pgp
Description: PGP signature