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.html
