On Wed, 22 Mar 2023, Jeffrey Walton wrote:
To counter the lack of pre-release testing, schedule another release T+x days after the release of interest.
The point of the "cool down" period after a release is to allow that *possibility*. We can do it if we feel we need to.
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.
Sure, master is always hot for curl as well. That's not why we do feature freezes and cool down periods. We do them because
A) merging features is riskier than fixing bugs. There is always the risk that something minor changed in a way that we didn't intend and that something needs an additional follow-up polish. By making sure we don't merge features too close to the release we reduce the risk that we ship problems caused by new features.
B) by clearly articulating that "now we work on bugs" we communicate how we take fixing problems before a release very seriously and that we rather not waste maintainer's time and efforts on merging features then, but they are rather encouraged to help polish off any remaining rough corners.
C) We like a clean linear commit history, so if we want to do a patch-release a week after a previous release, we better not merge any features into master before that patch-release happens.
-- / 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
