Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: On more stable curl releases
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 00:10:56 +0100 (CET)
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.
Date: Wed, 22 Mar 2023 00:10:56 +0100 (CET)
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.
-- / 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.htmlReceived on 2023-03-22