Re: On more stable curl releases

From: Sam James via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 01:13:35 +0000

Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> writes:

> On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote:
>
>> Some examples of regressions would be the crash that prompted
>> yesterday's 8.0.1 point release, the noproxy host matching bug #9842
>> (fixed in 7.86.0) and the wrong units bug in --write-out
>> %{time_total} (fixed in 7.75.0). Of these three examples, one
>> resulted in a point release while the other two did not.
>
> BTW, "regression" is just another word for "test coverage gap", since
> if we had tested the thing we would've detected the problem and the
> bug would not have been shipped. It is important that we learn from
> the regressions and improve the tests every time.
>
>> To look at it another way, between tags 7.75.0 and 7.88.1 (17
>> versions of commits), 32 commits say "regression" in the comment,
>> averaging 1.9 regressions per release.
>
> That is probably counting low since we don't always highlight them
> being regressions. Also, a regression can of course be something that
> *once* worked but that does not necessarily mean that it worked in the
> most previous release. It can also be five years ago.
>
>> I would like to see patch releases more often that include fixes
>> that target regressions.
>
>> A point release would only contain regression fixes and other fixes
>> deemed low risk.
>
> I agree that we do ship a certain rate of regressions and we fix them
> in subsequent releases.
>
> I understand your thinking with your proposal, but I am scared of
> going that route: because either we need to do the patch release
> management in a separate branch, so that we can allow the main branch
> to merge features for the next feature release and then we get a huge
> test and maintenance challenge: meaning we need to do everything that
> in two branches. Gone are the days of simple git history.
>
> Or we don't do different branches because the testing would be too
> difficult to handle. Then we need to handle this in the main branch
> and then it seems like we would basically not merge lots of things
> into the master branch for several weeks after a release. Also not
> ideal.
>
> I instead propose this much smaller and simpler change:
>
> We lower the bar for doing follow-up patch releases for regressions
> reported already within the period between the release and the
> re-opening of the feature window. For such we can do another release
> again already within a week or two. It is usually good to not stress
> them too much since then we get the chance to also find and fix other
> issues in the patch release.

Yes please. This'd be a big help for distributions. It means we don't
have to rely on additional bug reports in a distro it find out about
something fixed a day or two after the release.

best,
sam

>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2023-03-22