Re: Crazy idea: removing version numbers from debian
> A Debian package is either unstable, (testing) or stable.
> And everybody should use the package that fits his needs.
> Debian is evolving constantly, not in single steps.
> But I am interested
> what you think about this crazy idea to remove
> version numbers (like debian2.2) from debian?
I had a similar thought this weekend.
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.
New packages would not be allowed into stable until x days had passed in
unstable status without a Release Critical Bug.
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. If you need a buggy package anyway, get
it out of unstable.
Or perhaps any package lives in unstable, and instead of kicking packages
out of stable if it has a RCB, the BTS would interact such that the author
or "someone trusted" can specify the newest "old" version that does not have
There are events like libc upgrades where pretty much everything needs to be
recompiled. This issue must be dealt with.
In theory this would complicate support because there would be so many
"versions" of debian, yet developers survive with "daily" versions...
Finally the idea I like the best is no numbers, only named updates.
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.