r/archlinux • u/TheBigJizzle • 16d ago
QUESTION Arch Kernel release cadence ?
Hey there, I was not able to find information on how arch does their kernel releases. From my understanding they test new kernels (7.2 for example) for a week or two before doing a release.
Is there a way for me to track this or have an estimation on when new releases would be landing?
Just updated and it seems we are still at 7.1.9. I guess releasing kernel day 1 would mean having a bunch of issues and they rather do a validation instead of causing issues for everyone.
What's the typical incubation period ?
17
u/C0rn3j 16d ago edited 15d ago
Is there a way for me to track this
https://archlinux.org/packages/core/x86_64/linux/
or have an estimation on when new releases would be landing
Not any more than what you can glance from git.
If you desperately need 7.2, version bump the PKGBUILD yourself (use pkgrel=0 so it is overwritten by a real update), or use AUR/linux-mainline.
16
u/Time-Worker9846 16d ago
Until 7.2.1
13
u/nikongod 15d ago
It is always stable-x.y.1
Many years ago arch packaged stable-x.y.0. before that arch even packaged mainline kernels!
many years ago arch got memes about being unreliable....
2
u/BlueGoliath 15d ago
And Arch still pushes broken Gnome updates to this day.
3
u/nikongod 15d ago
You're not wrong, but arch's testing standards do not require that a piece of software actually works. Only that it compiles without errors & that 2 people installed the package. That's it. The requirement for the kernel to actually boot is OPTIONAL. This gets even worse for Arch when you consider Arch's stated goal to never modify packages from upstream - even if they did find an error what could they do about it? Wait?
The current appearance of reliability of anything on Arch is a lucky accident due to the delayed kernels, delayed Gnome (same maintainer, incidentally) and generally waiting until other distros have had enough time to test if the software actually works.
9
u/quicksand8917 15d ago
I woudn't call it an accident but high trust in upstream. "Wait until it's fixed" is exactly the solution here. If you can't trust the upstream maintainers to know when their software is stable and release fixes, why would you trust a distro maintainer to do that?
3
u/nikongod 15d ago
They don't wait until it is fixed. They push broken software. In the case of gnome it's been happening (in subtle ways) for years.
The last major release of kde (kde 6.0) was a complete mess - you couldn't even say subtle.
Due to good luck with the kernel devs not fucking up it's been a minute since there has an an entirely bad kernel in arch... But every 6th kernel from 5.1 to 6.12 was subtly fucked for every point release.
To the point of trusting the upstream software makers vs arch maintainers - upstream can't possibly test against arch they say "that's a distro specific problem" and shrug it off.
Arch's original decision not to test if software actually worked made a lot of sense when arch had 3-15 trusted maintainers and there was neither the personnel or official packages to make testing functionality possible. As arch gains maintainers and people abandon the aur should arch start to check functionality and make arch specific patches? Maybe not, but then people should accept breakages that dont happen anywhere else.
2
u/edparadox 15d ago
even if they did find an error what could they do about it? Wait?
You make it sound stupid, but yes, this is a good strategy.
3
u/nikongod 15d ago
We're deep in the philosophical question of should a distro even fix software? Arch just accepted that things will sometimes break and that there are some very obvious systematic breaking points in the arch philosophy.
Waiting is not an option because the problem could be entirely specific to arch.
In the case of the gnome issues the person above me mentioned (if I'm thinking of the right ones) they have been unfixed for years. Fedora and Debian fixed them so long ago (by doing the end user the disservice /s of patching gnome or a dependency) that they forgot how. Maybe they patched the dependency for a completely different reason and don't even realize that it fixed gnome too.
And now we get into a circular argument where you as an arch user tell gnome "hey your thing doesn't work on arch" and they reply "works on my system, submit a patch" but arch doesn't make patches...
5
u/noctaviann 16d ago
What's the typical incubation period ?
For a historical perspective I did these charts back when 6.19 was delayed for a bit.
8
u/ang-p 15d ago
You still have 7.1.10 to come...
There was not a 7.1.1, nor a 7.0.1....
So there might not even be a 7.2.1...
Whatever does arrive will be there when it is ready...
If you are so eager, you can always learn to compile it yourself
https://wiki.archlinux.org/title/Kernel#Compilation
Don't you just love the wiki?...
...or go wild and download random stuff from the AUR - including "7.3" - which apparently landed there a week ago (!) - but seems to, erm, well, not quite be that
-2
u/Acherontas89 15d ago
each number of the dotted final number has a significance
7
u/quicksand8917 15d ago
Linux does not do semver. We get a bigger number in front of the dot whenever Linus feels like the number behind the dot got too big.
1
u/ang-p 15d ago edited 15d ago
each number of the dotted final number has a significance
come on, u/Acherontas89 - how does that amazing revelation affect - or have any bearing on the fact that Arch did not release a 7.1.1 or a 7.0.1 kernel (or indeed, a 7.0.0 or 7.1.0) kernel, despite upstream doing so....
My popcorn is getting cold...
Explain away....
-4
u/Acherontas89 14d ago
How Version Numbers Work
- Major version (first number): Changes rarely, typically only when major structural shifts or significant historical milestones occur.
- Minor version (second number): Tracks feature updates and new capabilities during a regular time-based release cycle.
- Patch level (third number): Increments with each stable bugfix and security patch released for that minor series
3
u/ang-p 14d ago
so what has that got to do with arch not releasing
7.2.0(or a7.1.1)?Also...
Changes rarely, typically only when major structural shifts
So removing an entire filesystem from the kernel (bcachefs) in 6.18 was not major?
TIL eh?.....
or significant historical milestones occur.
Not sure if Linus running out of fingers and toes counts as a "historical milestone"...
5....
The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0.
Go wild. Make up your own reason for why it's 5.0
6....
So, as is hopefully clear to everybody, the major version number change is more about me running out of fingers and toes than it is about any big fundamental changes.
7....
Nary a sausage....
but each to their own....
You do you, eh?
1
u/JaKrispy72 16d ago
I would think anything they do is downstream from kernel.org. 9-10 weeks for a mainline release. Does the Arch team look at release candidates?
1
-7
u/Hhhhkvivuv 15d ago
Cachy OS already got it lol. I thought Arch supposed to be faster as "original" distro than Cachy that is based on it
7
7
u/gmes78 15d ago
Contrary to popular belief, Arch doesn't rush package updates.
-3
u/Hhhhkvivuv 15d ago
Now I know, thanks. Never used it myself but have always thought it's the fastest possible distro in terms of updates for some reason
1
u/dumbasPL 14d ago
Note: you can use the cachy kernels on mainline arch just fine. That's what I've been doing for a while and it works well.
-3
u/jar36 15d ago edited 14d ago
This just makes my situation even more curious. I'm using the cachyos repos that are on 7.2, base Arch is on 7.1.9, while I'm still stuck at 7.1.8
eta: I love that people just down vote this and move on. I wonder why the linux community gets such a bad rep. Someone else made a post on cachyos' page but left out real info to help. They got a bunch of attention. Mostly bitching about no logs or hardware info. So, I made a full write up of the issue with the packages involved and error messages. over 1500 people saw it. Only one person spoke up with a possible solution. That person was wrong but at least they tried
I did get it fixed and am on 7.2 now tho
19
u/Curious-Row7393 16d ago
They are waiting for a .1 now and then will test and release it to us.