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 09:17:48 +0100 (CET)
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.
Date: Wed, 22 Mar 2023 09:17:48 +0100 (CET)
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.
-- / 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