←back to thread

147 points nitinreddy88 | 1 comments | | HN request time: 0s | source
Show context
rurban[dead post] ◴[] No.42170111[source]
[flagged]
bonzini ◴[] No.42170298[source]
There's no minor and major. All releases are equivalent but the first number is bumper when the second becomes large enough, which happens every 2-3 years.
replies(2): >>42170403 #>>42170988 #
yjftsjthsd-h ◴[] No.42170403[source]
In fairness, that is a weird versioning scheme, and I really do wish that Linux either switched to full semver (in which case it'd be version 2.9000.0 or so by now) or just drop the leading digit and go full build number kinda like NT does. But as cousin comments note, not my project not my call:)
replies(4): >>42170564 #>>42170621 #>>42171003 #>>42171115 #
usr1106 ◴[] No.42171003[source]
Full semver is an illusion. It's often debatable what is a new feature (we support a previously unsupported functionality) vs. what is a bug fix (it did not work correctly before).

Also what is a non-compatible change is not always clear. Did the user do it wrong in their existing code or did the project make an incompatible change?

The kernel has said for long times that they don't make incompatible changes. We don't break user space as they say. So you could prefix their numbers with an imaginary "1.". Of course sometimes opinions vary, whether a change breaks userspace or breaks wrong code.

That said the kernel numbering scheme is weird. Increasing the first digit after 19 *or* 20 is less logical than imperial units.

replies(1): >>42171948 #
1. bonzini ◴[] No.42171948{3}[source]
> The kernel has said for long times that they don't make incompatible changes

Which is also not entirely true, as sometimes bad or obsolete functionality is dropped (e.g. /dev/mem). Given how big the kernel is, probably all versions would be a semver bump for one of it's many subsystems.