> Am 22.03.2023 um 00:10 schrieb Daniel Stenberg via curl-library
> <curl-library@lists.haxx.se>:
>
> 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.
Yes, test coverage for regressions is the only thing that works *and* allows us
to evolve.
>
>> 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.
Speaking from experience in Apache httpd, release branch costs are considerable.
> 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.
Delaying the opening of the feature window after a release seems to be a good
balance. Right now, I have several PRs pending for the re-opening of the window
and it does not cost anything to have them wait a week more. Feature branches
already exist. Maintenance branches we'd like to avoid.
Kind Regards,
Stefan
>
> --
>
> / 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
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
