Re: post-release package update policy
email@example.com (Thomas Kocourek) wrote on 03.11.95 in <firstname.lastname@example.org>:
> I propose that the "Packages" listing be frozen as the official list of a
> release. Thus it would be the necessary "snapshot" showing which packages
> are guaranteed to work together as a release. I also propose that a second
There's only one problem with this. The current way of doing releases
makes no such guarantee.
To make such a guarantee, we'd have to do what Linus does with the kernel:
At some point, we'd have to declare a code freeze. Only bug fixes would be
allowed in, until we were reasonably certain that the system is "good
enough". Then, we'd release *that*. (And, by the way, continue to make
bugfixes to it, if the bugs found later are bad enough.)
This would, of course, completely screw pre-announcements like "Debian
93.6 will be available on ...". But considering how the last one went,
that might actually be not so bad ...
Anyway, *if* we go this route, I'd suggest having the master file say
something like "_these_ packages are considered to be the current stable
release, and _this_ is the list of packages updated into that stable
release since the release, and _these_ are the other updated packages
available that are meant for beta test and a future release".
[ Note that the second list is included in the first list. Packages
replaced in the release because of serious bugs aren't useful to mention
there, I think. ]
In a human-readable text file, please; think "new user".