Re: Considering a version 8 at some point...

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
Received on 2020-07-01