Re: Crazy idea: removing version numbers from debian
vlm@execpc.com (Vincent L. Mulhollon) writes:
> Perhaps any package can live in unstable, but any package that has a
> release critical bug older than 1 week is zapped from stable and placed back
> in unstable. Upon next package upload, it will be reinstated into stable.
Ack! Can you imagine what would happen under that system with a package
whose bugs are not handled that quickly? The version in stable would be
$foo, next week it's $foo.1, a week later it's $foo again because of a RC
bug filed in week 1, another week passes and the bug is fixed, so it's
$foo.1 again. Not to mention we'd have to start supporting downgrades as
well as upgrades (although I'm a new developer, I'm fairly sure we don't
do that).
> New packages would not be allowed into stable until x days had passed in
> unstable status without a Release Critical Bug.
Then someone files one when the maintainer's on vacation, nobody has time
to do a NMU, and it pops back into unstable. Ick.
> Or perhaps any package can live in unstable, and every package has a copy of
> itself in unstable, but on the last day of the month it is kicked out of
> stable if it has an open RCB. If you are picky about RCBs, only apt-get
> stable on the first of the month.
What if a RC bug is filed the day before the deadline? Last day of the
month hits, users apt-get dist-upgrade and then are faced with having to
downgrade their software.
> If you need a buggy package anyway, get it out of unstable.
Better yet, don't put packages into stable until we release. "Stable"
has a fairly well-defined meaning; I don't see much benefit from changing
it.
> In theory this would complicate support because there would be so many
> "versions" of debian, yet developers survive with "daily" versions...
But because those "daily" versions are numbered, we know that the version
we're getting is the latest (or not, as we choose). How do you tell
somebody "I know that was fixed in the version I uploaded last week;
don't download today's though, as it's known buggy" without using version
numbers? You could use dates, but that can get hideously complicated
very quickly.
> Finally the idea I like the best is no numbers, only named updates.
See above. Numbers make a lot of things easier.
> And we'd have a goal for the name. Like the goal for "whiskey" release
> would be every package that needs it supports debconf, or the goal for
> "vodka" is every package supports kernel 2.4 and IPv6, or the goal for
> "scotch" is every package supports perl 5.6 or whatever.
A great idea. But can't we do that now?
-=Eric
--
Any philosophy that can be put in a nutshell belongs there.
-- Sydney J. Harris
Reply to: