Posted Oct 8, 2009 17:22 UTC (Thu) by iabervon (subscriber, #722)
In reply to: 2.6.x-rc0 by k3ninho
Parent article: 2.6.x-rc0
The problem is that people want to base their development on kernels that don't have lots of instability in them, so they pick a tag from Linus's repository that is likely to be stable, and that tag has a version in the Makefile like "2.6.31". When they start their feature, it's completely unstable, but has a "2.6.x" version. When subsystem maintainers put together series, they pick up these topics, and they don't change the Makefile version themselves (since they don't maintain the Makefile), and the don't merge Linus's tree, especially not during the merge window (because that creates a lot of cross-merges and useless merge commits and cases where things from -system1 are broken because of a change in -system2 merged first into the merge window and them into -system1).
The end result is that, regardless of what Linus does, if there is a commit which builds a kernel that claims to be "2.6.x" in his tree, then most of the least stable commits in his tree will also claim to be "2.6.x".
One thing that might work would be for Linus to not put "2.6.x" in his tree, but instead put "2.6.x+1-rc0" in his tree and only put "2.6.x" in the 2.6.x-stable tree. This would have the nice side effect that string compare would start sorting tags within a tree correctly, and it's obviously equivalent to the current situation at a string-equality level within a given tree, but I don't know if Linus would like not having releases ever cut from his tree any more.