+1 for LTS pursued along more commercial routes. Jim
On Wed, 1 Jul 2020 at 17:57, Dan Fandrich via curl-library <curl-library@cool.haxx.se> wrote: > > On Wed, Jul 01, 2020 at 10:33:55AM +0200, Kamil Dudka via curl-library wrote: > > I think the key question is who would maintain such an LTS branch in > > upstream. > > Maybe some of the distros maintaining their own LTS branches of curl would > sponsor such a branch? Right now, there are several people in your shoes, > doing the same difficult job of backporting security fixes using several curl > releases as a baseline. Pooling resources would mean less work for everyone. > > The big downside is the lack of choice on the baseline version to use as an > LTS > branch. RHEL and Ubuntu releases (for example) are based on whatever Fedora > or Debian happen to have in their repos at the time the LTS release is cut. > Switching libcurl to an LTS branch that might be a year or two older would be > pretty disruptive. > > Maybe a better approach would be to get some embedded users to sponsor an LTS > branch, since they usually have more flexibility in what version they choose > for their products. That also might not be so straightforward either since, in > my experience, most embedded companies don't really care much about security. > But, it might work if only a handful of companies pony up. > > Dan > ------------------------------------------------------------------- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
