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: Thu, 23 Mar 2023 00:04:29 +0100 (CET)
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.
Date: Thu, 23 Mar 2023 00:04:29 +0100 (CET)
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.htmlReceived on 2023-03-23