[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

1 year release good enough.


I was wondering about the 2 year release cycle of Debian and it's adaptability on the Desktops.

You have to admit that Debian is not used used much on the Desktops -- it appears to be more popular for servers; and the 2 year release cycle is good for servers; increasing the release cycles to a higher amount is also not bad when it comes to servers. Cause servers don't have to care much about hardware compatibility and changes in protocols/formats following the limited amount of task they do, or they don't require periodic updates to installed software.

On the desktops however, in the above context, things differ completely.
There's new hardware available always; within a period of 2 years, the generation of hardware changes requiring new drivers. Backports are available, but usually after a timeframe of 1 year, it's unlikely that the backports can be made available for 1.2 year old packages (they require newer build time dependencies). Using apt-pinning, you can upgrade the libraries but these can break stable applications, and often you have to upgrade practically the whole system cause of some dependency (like glibc) being unsatisfied.

An upgrade of X drivers is yet more complicated, not to mention backporting ATI and Nvidia drivers become yet more complicated and often impossible in a system more than 1 year old.

Apart from hardware compatibility, newer standards (like HTML 5, h265, document formats etc...) are a necessity for a the Desktops but backporing the corresponding program may not be possible because of very old libraries.

Further, Desktop systems dont require that much of stability and reliability and even security many times.

As a consequence, I suggest a sub-stable branch who's release cycle will be 1 year. As compared to the stable branch, this branch should be more flexible to upgrades and even downgrades -- our objective should be to include the software version in the sub-stable branch which apparently have the least bugs and other critical issues -- for e.g. KDE 4.7 has a lot of new small bugs as compared to 4.6 -- I've to say KDE 4.6 was better in terms of number of bugs, thus the sub-stable branch should continue to include the 4.6 release of KDE. If a major upstream bugs or issue is found in a package, it'll be upgraded.

After one year, this sub-stable branch will be declared stable -- thus the stable branch will have even more stability and reliability, it being tested and correspondingly upgrade rigorously while it was in sub-stable.

Since there's a new branch, there'll be additional loads on the developers (backports and all that), I suggest the unstable branch be demolished (I'm not clear about it's role though) and increase the migration time from experimental to testing.

Reply to: