←back to thread

149 points nitinreddy88 | 1 comments | | HN request time: 0.208s | source
Show context
rurban[dead post] ◴[] No.42170111[source]
[flagged]
aorth ◴[] No.42170139[source]
A new major release of the Linux kernel happens every ~8 weeks. There are usually 7 or 8 release candidates (-rc1, rc2, etc) released on successive Sundays during that period, followed by a release of the major version. That's the workflow the Linux kernel has used for years.
replies(1): >>42170234 #
rurban[dead post] ◴[] No.42170234[source]
[flagged]
sevg ◴[] No.42170289[source]
What a strange comment. Are you trolling?

Yes, projects can use their own version scheme.

The Linux kernel has been using this version scheme for over a decade. If you think it's inconsistent then that's a you problem.

replies(1): >>42227814 #
rurban ◴[] No.42227814[source]
My problem is that Linus didn't bump it on this major change. His versioning scheme is that he bumps whenever it feels like it.

So decades of work to make it finally real-time safe is not worth it. This shows his precedences. It's not latencies. The industry will recognize

replies(1): >>42227936 #
1. sevg ◴[] No.42227936[source]
No, the versioning scheme is that the first two numbers are the major version.

From https://en.wikipedia.org/wiki/Linux_kernel_version_history :

> Each major version – identified by the first two numbers of a release version

For the last decade, the first number gets bumped once the second number reaches 19 or 20. This has been consistent since 3.x.

> So decades of work to make it finally real-time safe is not worth it.

Haha you can't actually be serious? Thomas Gleixner's goal was to get Real-Time patches merged, not to get an aesthetic version bump, because nobody cares about the version number.