> 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 the bug. 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.