curl / Mailing Lists / curl-library / Single Mail
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

From: Jeffrey Walton via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 11:02:40 -0400

On Wed, Mar 22, 2023 at 4:17 AM Daniel Stenberg via curl-library
<curl-library_at_lists.haxx.se> wrote:
>
> On Wed, 22 Mar 2023, Stefan Eissing wrote:
>
> > 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.
>
> So, how about this for adjusted release cycle and release management:
>
> - Increase the post-release ("cool down") margin before we open the feature
> window. We currently have it 5 days, we could double it to 10 days. That
> would then reduce the feature window with the same amount of days leaving
> us with 18 days to merge features.
>
> - Within the cool down period, we are only allowed to merge bug-fixes.
>
> - Lower the bar for a patch-release. Even "less important" regressions should
> be considered reason enough to do follow-up releases. And if they are not
> reported within the cool down period, chances are they are not important
> enough.
>
> - After a follow-up release, we start over with a new cool down period of 10
> days.
>
> - If we decide to do a patch release due to a regression, we set that release
> day N days into the future so that we can accumulate a few more fixes and
> get our ducks in order before we ship it. N is probably at least 7.

The last item is the important one due to lack of participation in
pre-release testing. You can ask for testers until you are blue in the
face, but you are only going to get a handful of testers. People won't
test the release until it is released.

To counter the lack of pre-release testing, schedule another release
T+x days after the release of interest. So if you release cURL 8.0.0
on January 1, then you schedule a 8.0.1 maintenance release on January
14 or January 28. You use the 10 days or 2 weeks to clean up the bugs
that crept in but were not caught in pre-release testing.

I don't know how that intersects with the "cool down" or feature
window. I don't use them. In the projects I work with, master is
always hot - it is always in a release state. Feature development and
testing happen in a fork on a branch, so it does not taint master
which is always hot. In fact, because it happens on a fork, it does
not even taint the project itself.

Another person came up with the strategy to counteract the lack of
testers. He told me I would not get enough testers to find the bugs we
hoped to catch before a release. I did not believe him. He was right.
Now I plan for the lack of testers by scheduling a maintenance release
following the release of interest.

Jeff
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2023-03-22