6 ms·

As others have chimed in, while working extremely well for _libraries_, which I believe Semantic Versioning was really proposed for in the first place anyways,

As others have chimed in, while working extremely well for _libraries_, which I believe Semantic Versioning was really proposed for in the first place anyways, it does not work or necessarily make sense for Kernels which are kind of a very special kind of library. Once matured, kernels tend to never break backwards compatibility (or try very hard not to), and rarely track bug fixes with individual numbering. Often many changes are lumped into a single version update, because so many changes are already happening across many different subsystems. I suppose also, now that I think about it, Semantic Versioning works much better for smaller scoped and smaller scale projects (like well scoped and designed libraries). The kernel is such a large piece of software almost like a collection of libraries hidden behind a single set of matures APIs that incrementing counters for every bug fix or tiny change doesn't make sense---and as has been established, major numbers would just never bump.

lucb1e 12y ago
This makes sense, but then why have a version number that looks like semantic versioning? If they are randomly jumping major versions (2.6 -> 3, now to 4) they might as well drop the major version altogether. Why not go for a release number (e.g. r85) and a patch number for hotfixes (e.g. r85.2)?
- pas 12y ago
  There are no hotfixes (from Linus, the stable branches are a different matter). And basically the release is just a snapshot of updates that happen to build together with some nudging and silly letters from Linus. Best would be to just go and use a year.month number. 2014.12, 2014.02, 2015.04. But ultimately, it's just a semi-unique identifier with a lot of context that one should be aware of. (And it's not like you can go and buy a Linuks 4 in stores right now, or just put it into your requirements.txt. So confusion is very minimal, it's just a "tag".)
  - NeutronBoy 12y ago
    I actually thought that, but you'd still end up with things like 2014.12-r7 because you end up creating different versions when you backport fixes.
- 4ad 12y ago
  Because the semantic versioning meme appeared tens of years (!!) after people started using x.y.z versions for software (including Linux).

lucb1e 12y ago

This makes sense, but then why have a version number that looks like semantic versioning? If they are randomly jumping major versions (2.6 -> 3, now to 4) they might as well drop the major version altogether. Why not go for a release number (e.g. r85) and a patch number for hotfixes (e.g. r85.2)?

pas 12y ago
There are no hotfixes (from Linus, the stable branches are a different matter). And basically the release is just a snapshot of updates that happen to build together with some nudging and silly letters from Linus. Best would be to just go and use a year.month number. 2014.12, 2014.02, 2015.04. But ultimately, it's just a semi-unique identifier with a lot of context that one should be aware of. (And it's not like you can go and buy a Linuks 4 in stores right now, or just put it into your requirements.txt. So confusion is very minimal, it's just a "tag".)
- NeutronBoy 12y ago
  I actually thought that, but you'd still end up with things like 2014.12-r7 because you end up creating different versions when you backport fixes.
4ad 12y ago
Because the semantic versioning meme appeared tens of years (!!) after people started using x.y.z versions for software (including Linux).