In the curl project we ship new releases based on the master branch of our git repository, in a clean and linear commit history. We have never maintained an old branch for long term or stability etc. Instead we promise to not break user behavior nor the ABI or API. All users should be able to always upgrade to the latest.
A never-ending stream of releases you can always upgrade to; a new one every 8th week.
We build infrastructure you can lean on.
But
Sometimes reality does not match our intentions and we ship regressions.
Sometimes users are too scared that there might be a regression so they refrain from upgrading. risk averse is probably how they view themselves.
Sometimes users, organizations and Linux distros have policies that say they do not upgrade versions. Usually based on how software in general works and there needs to be a single fixed policy for managing software versions and then curl gets treated the same way.
For those situations and other related scenarios, repeating the top paragraphs does not help.
long term branches by others
In practice, just about every major Linux distributor maintains one or more stable curl branches. They backport security fixes to those versions to keep them secure for their users. Some vendors also merge selected bugfixes into their branches.
Every Linux distributor picks the particular curl version they stick to by themselves without coordination with other distros. They all do it at different times and they all have their own specific criteria and work processes for doing this. This, in combination with curl’s frequent releases, tend to make them all pick different versions for their different branches. And keep them alive for different lengths.
Some vendors maintain their stable branches for extended periods of time. Upwards and beyond ten years happen.
These long-lived branches may eventually end up having literally hundreds of patches applied to them. The curl builds done from these branches still report as version x.y.z but in reality they are mutated versions that can be significantly different compared to the original x.y.z version that the curl project shipped in a tarball back in the day.
That’s the comfort you get for picking (and paying?) a Linux distribution. (Yes, you also easily get stuck with an ancient version because of this.)
Some users also simply get stuck on older versions for other reasons and do not security-patch them over time (by ignorance or incompetence), making them more and more insecure over time.
Reality
At the time I write this post, the curl release with the largest number of known security vulnerabilities has 85 published CVEs.
By asking users and by looking in logs in various servers, we know that just about every curl versions we have shipped the last dozen of years or so remain in use somewhere. We can only hope that most of them are security patched.
In reality, every release we do becomes a long term release for someone.
Long term support?
Every once in a while a discussion pops out in or close to the curl project whether we should consider starting to maintain one or more LTS branches.
We have never completely dismissed those ideas. We are however acutely aware of the extra effort and energy such an endeavor requires, so we have so far shrugged it off. But should there come users and sponsors willing to help make it happen, we would not be shy of implementing something.
After all, the ones most interested in LTS branches are usually people and companies with an economic gain to be had; with businesses using and relying on a rock solid curl. They should then also be able to help pay for this.
If you or the company you work for would be interested in something like this, please reach out and we can get the conversation going. Maybe we can do something to improve the lives of people out there?
Until then, we stick to a single release branch.
Credits
Image by Julius Silver from Pixabay
