Re: post-release package update policy
Clearly we need both a `stable' and an `experimental' system.
However, bugs in the `stable' system will continue to be found, and
will have to be fixed. We must therefore not cast the `stable' system
in stone.
We should therefore make the stable vs. experimental distinction on a
per-package level too.
Packages should initially be released into the experimental system,
and then when the particular version has proved stable we can move it
into the stable system.
This will not, of course, deal with interdependencies between
different versions of different packages. However, that problem can't
be solved by snapshotting the release, either: a snapshot would simply
have all the bugs that were present at a particular time.
We should deal with version dependencies by having package maintainers
think carefully about interrelationships before asking for a version
to be moved into the stable tree. I don't think there is any way we
can arrange for this problem to solve itself: we will have to put
thought into these issues every time they occur.
Ian Murdock writes ("post-release package update policy"):
> What should our policy be with regard to adding, replacing, and
> updating packages under the debian-0.93 tree after the release?
>
> Some suggest that it would be best to leave debian-0.93 alone after
> the release, and that instead of moving new and updated packages into
> debian-0.93, we should put them in a different (but easily-accessible)
> tree, such as debian-updates-0.93. The advantage of this approach is
> that it gives users access to both the "released" and completely up to
> date distributions. The disadvantage is that users would have to make
> a decision as to which of them to install.
The worst disadvantage is that neither would be suitable for use - the
frozen tree would be full of bugs that were fixed in the updates
tree, and the updates tree would be full of broken packages with good
versions in the stable tree.
Let me look at it another way:
We have two trees, stable and experimental. Each contains a
particular version of each package. We should not decide which
version of each package to put in the stable tree merely by release
date of the package in question. We should base this decision on all
the available information, including whether or not there are serious
and urgent bugs in the current `stable' version, whether the new
version will work with the other stuff in the `stable' tree, &c &c.
> Others suggest that we should keep doing what we're doing now--that
> is, as packages are released, we should move them into debian-0.93.
> The advantage of this approach is that users are guaranteed to have
> all fixed and updated packages at the time they download the
> distribution. The disadvantage is that a release of Debian GNU/Linux
> becomes a constantly moving and shifting target instead of something
> tangible. Alot of people complain that this is a major problem with
> how we make releases.
The worst disadvantage is that the resulting tree would not be
suitable for use. This is simply the same as the `upgrades' tree,
folded into the `stable' one.
We definitely need two complete copies of the distribution, one with
the latest bleeding-edge of everything, and one that has the latest
stable version of each package modulo all the versions in it working
together.
I was under the impression that debian-0.93 (aka debian-current) was
going to be the stable copy, and that debian-1.0 was going to be the
experimental version (which would presumably start out with a.out
versions of everything and gradually move to ELF).
Perhaps we need three trees, a stable a.out, an experimental a.out
and an ELF ?
We have a very powerful modular approach to system integration - let's
not throw that out of the window by insisting on arbitrary flag days
and snapshots and the like.
Ian.
Reply to: