3 ms·

In my experience, bleeding edge and stable are about the same amount of pain. Breakage isn't actually that common, and fixes come a lot faster. And even if you

In my experience, bleeding edge and stable are about the same amount of pain. Breakage isn't actually that common, and fixes come a lot faster. 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.

ilyt 3y ago
That seems to be mostly bathtub curve for most of the software for us when it comes to amount of work. 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