Re: Mirrors et al.
[ Warning: I'm going to rant on release engineering again. I still don't
know anything about it first hand. ]
Craig Sanders:
> Why have 0.93, 1.1, 1.2 version numbers at all?
>
> Why not have version numbers like: 960429, 960615, 960722 etc.
>
> CD manufactures want version numbers? Fine, they can have them. YYMMDD
> of whatever day they cut the CD. YYMMDD is the only date format that
> sorts properly...so I use it for everything.
>
> Who else *needs* a version number for Debian?
Many people need clearly identified releases:
* CD-ROM producers
* overworked sysadmins
* busy users, who administer their own systems
* Debian advocates (on comp.os.linux.advocacy, etc)
All these people have the same need: they must be able to say "Debian
version FOO" or "Debian version FOO with all fixes as of YYYYMMDD".
"FOO" can be 1.1 or 19960401 "Leonardo da Vinci" or whatever, it doesn't
matter, but it must be unique, and it must clearly identify a known set of
packages. Version numbers (of any format) and releases go together.
The problem is that a snapshot of ftp://ftp.debian.org/debian/unstable/
taken on any random day is not guaranteed to produce a set of packages
that work together.
For a CD-ROM producer, this means that customers will complain about
Debian not working for them. If they care about their reputation, and
the problems are sever, they will have to cut a new disk and give it away
for free to people who complain.
For an overworked sysadmin, it means that either they have to be upgrading
packages daily, or else they may have to suddenly upgrade many things even
if they really only want to upgrade one, if the interesting one depends on
many newer (or completely new) packages. Sysadmins have better things to
do. Unless there are important problems, they would prefer to install
something that is known to work, and then not be bothered about installing
new software until the next major release. Meanwhile, they will be
overworked with handling bad hardware, stupid network providers, mail bombs,
stupid users, malicious hackers, and upper management.
Busy users who administer their own systems are in the same position
as sysadmins.
Debian advocates can't very well go around saying that Debian is so good
that it works for everyone, if most days anyone downloading everything from
an ftp site won't be able to get everything to work.
> this is one of the features of the dpkg software - we should promote it
> as such.
dpkg is very, very nice and Ian J is my, well, perhaps not quite god, but
at least an angel. (I don't say the same for dselect. I hate the UI.)
Unfortunately, dpkg can't and doesn't solve all the problems. Say a few
important packages are updated. Like the kernel and init. The new kernel
changes something that breaks init, so if you upgrade the kernel, you must
upgrade init as well. The maintainers of both are devoted to Debian and
make new releases simultaneously. Unfortunately, the init maintainer
has network problems, and can't upload the new version for a week. The
kernel maintainer has no such problem, and uploads immediately.
During the whole week no-one can download a working Debian.
Not good.
If there is a release, the new kernel would be put in unstable, making the
unstable directory non-working. But that's OK, since that's what it's for.
The release directory would be frozen, and would still contain a working,
internally coherent set of packages, even if some of them might have been
updated by other packages, and even if it might contain problems fixed
by later packages.
Note that a release directory should be frozen. Fixes should be kept
separate. Or else the fixes must be tested well enough that if the package
is replaced, the resulting set of packages works at least as well as the
original release. Such a minor release might not need as much testing
as a full release, but it needs more than "this probably fixes the problem".
A work on version numbers. A YYYYMMDD (or possibly YYYY-NN, where NN is
a sequence number within a year) number is logical, and pretty easy.
However, the 1.1 kind of scheme, if used properly, makes it easier to
see when there have been large changes. The move from 0.93 to 1.1 is
big -- because of ELF. Later, similar moves might be made again.
For example, when multi-architecture support is included, we might move
from 1.x to 2.0. The major number might be upped also if the kernel
becomes a micro kernel, or the C library gets a major change (major number
of the library changes), or the primary filesystem is changed from ext2 to
a journalling one.
But this is a minor issue.
Reply to: