On Wednesday, July 1, 2020 9:09:02 AM CEST Erik Janssen via curl-library wrote: > > I agree with jumping to the version 8 as long as we define what would be > > the futur scheme post-8. > > > > - Having an important step forward/addition to the project? > > Would it make sense to keep version 7 as a 'Long Term Support' version that > receives bugfixes and security updates but no features? Version 8 would > evolve as normal with higher risk of facing issues when upgrading > > I think it does happen that people upgrade and notice things stop working. > An LTS version would add value for a part of the userbase. There is a risk > of course that some of the work doubles for you fine group of volunteers > > Erik
I think the key question is who would maintain such an LTS branch in upstream. I am maintaining curl-7.29.0 in RHEL-7 and curl-7.61.1 in RHEL-8, and it is not as easy as it sounds. The development in curl upstream is extremely fast and some improvements come with reworks of the internal API. Consequently, bug fixes applied on the development branch do not apply on LTS. Or even worse, they apply fine but they cause major breakages in case we do not pick additional changes that the fixes rely on. In 2018 I backported fix for CVE-2018-1000122 on top of curl-7.29.0, which caused `curl --limit-rate` to crash. The feature was not covered by upstream tests, neither by our integration tests. So the regression leaked through QE and we had to backport additional 11 commits in an accelerated update to fix the breakage: https://bugzilla.redhat.com/1683292 Kamil ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
