I have enough on my plate just dealing with the issues arising from using stable code, I think it’s admirable that people find the time raising their glance to future releases and helping us all enjoying a less panic-inducing experience.
We used to run -stable, and update every few years, like from FreeBSD 9.x to FreeBSD 10.x. We found that when we did that, we would often encounter some small subtle bug that was tickled in our environment, and which was incredibly hard to track down. That sort of bug was hard to track down because the diff between branches was enormous, and because there were thousands of commits to sift through, and because the person responsible for the bug may have committed it months or years ago, and has forgotten about it.
We eventually decided to track the main branch, updating frequently. This means that while we find more bugs, but they are far easier to fix because they were introduced more recently, and there are a lot fewer commits to look through to find where they came from.
For a lot of companies, inspecting source code and filing bugs directly is just not a capacity that exists, which is where LTS of a Linux distribution makes a bit more sense — and without throwing any shade on FreeBSD (I love it), maybe the smaller amount of users globally compared to Linux means that “stable” isn’t quite as stable, especially if you’re doing bleeding edge stuff anyway.
I guess you could say the same thing is true for a company like Cloudflare considering their network related patches to the Linux kernel.
Thanks for the perspective!
If you're just a consumer, then it makes a lot of sense to consume the LTS branch. Whenever I've run ubuntu (which I do not contribute to), I run LTS for that reason.
In our case, we have a team of kernel engineers who make frequent contributions and are very familiar with the FreeBSD source code. So we're in a good position to inspect the frequent merges from upstream.
The other benefit to tracking the main branch closely is that it makes it far easier to contribute changes. When tracking the main branch, its easy to test a change in our tree, and then pick it up almost unmodified as a patch to the FreeBSD main branch. That makes it much easier to get the code into FreeBSD. In fact, for most smaller changes, we try to push them upstream first and bring them back with our frequent upstream merges This is much harder when running a several years old branch, as then the patch needs to be forward ported to the FreeBSD main branch. As such, its very hard to integrate and test changes suggested by reviewers, as the patch needs to be ported back and forth. And things get worse for large changes (like new TCP stacks, kTLS, etc), which are harder to port back and forth.
Also, do you folks tend to review the freebsd code before upgrades or only after the fact (like, if there's a show-stopping bug or two)? Thanks.
And even if you perfer stable, the latest will become stable eventually. Not trying your workload out on the next releases has pretty much the same risk profile of just running latest.
Many problems can only be found by running your particular workload.
Running on "latest commit from master" from many projects (not Linux) will just get you code nobody even tested and so a lot of bugs fixed quickly.
Running on "latest stable" (whatever that means for project) means fixes from time to time when it updates, but in vast majority of cases not that much work.
Anything behind that like LTS releases ? Extra work.
Now any doc you find might be about never release or feature that changed. "Bugs" might not get fixed if they are not big enough to backport.
Upgrade to new LTS version will also get you years of changes in app that you then have to apply to the system, vs having to do it "change by change" when keeping up to date.
If you use configuration management that also often means multiple different configs to manage at the very least till previous LTS version gets finally upgraded
In fact, many of these bugs were on stable releases too.