From: Daniel Stenberg Date: Sat, 5 Nov 2022 22:50:32 +0000 (+0100) Subject: docs/EARLY-RELEASE.md: how to determine an early release X-Git-Tag: curl-7_87_0~204 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2d4533996c0ad47fa783c1202ea9997e7d45c920;p=thirdparty%2Fcurl.git docs/EARLY-RELEASE.md: how to determine an early release URL: https://curl.se/mail/lib-2022-10/0079.html Closes #9820 --- diff --git a/docs/EARLY-RELEASE.md b/docs/EARLY-RELEASE.md new file mode 100644 index 0000000000..396ba23606 --- /dev/null +++ b/docs/EARLY-RELEASE.md @@ -0,0 +1,66 @@ +# How to determine if an early patch release is warranted + +In the curl project we do releases every 8 weeks. Unless we break the cycle +and do an early patch release. + +We do frequent releases partly to always have the next release "not too far +away". + +## Bugfix + +During the release cycle, and especially in the beginning of a new cycle, +there are times when a bug is reported and after it has been subsequently +fixed correctly, the discussion might be brought up: is this bug and +associated fix important enough for an early patch release. + +The question can only be properly asked once a fix has been created and landed +in the git master branch. + +## Early release + +An early patch release means that we ship a new, complete and full release +called `major.minor.patch` where the `patch` part is increased by one since +the previous release. A curl release is a curl release. There is no small or +big and we never release just a patch. There is only "release". + +## Questions to ask + + - Is there a security advisory rated high or critical? + - Is there a data corruption bug? + - Did the bug cause an API/ABI breakage? + +If the answer is yes to one or more of the above, an early release might +indeed be warranted. + +More questions to ask ourselves when doing the assessment if the answers to +the three ones above are all 'no'. + + - Does the bug cause curl to prematurely terminate? + - How common is the affected buggy option/feature/protocol/platform to get + used? + - How large is the estimated impacted user base? + - Does the bug block something crucial for applications or other adoption of + curl "out there" ? + - Does the bug cause problems for curl developers or others on "the curl + team" ? + - Is the bug limited to the curl tool only? That might have a smaller impact + than a bug also present in libcurl. + - Is there a (decent) workaround? + - Is it a regression? Is the bug introduced in this release? + - Can the bug be fixed "easily" by applying a patch? + - Does the bug break the build? Most users don't build curl themselves. + - How long is it left until the already scheduled next release? + - Can affected users safely rather revert to a former release until the next + scheduled release? + - Is it a performance regression with no functionality side-effects? If so it + has to be substantial. + +## If an early release is deemed necessary + +Unless done for security or similarly important reasons, an early release +should never be done within two weeks of the release of the previous version. + +This, to enable us to collect and bundle more fixes into the same release to +make the release more worthwhile for everyone and to allow more time for fixes +to settle and things to get tested. Getting a release in shape and done in +style is work that should not be rushed. diff --git a/docs/Makefile.am b/docs/Makefile.am index 0d565796fa..581d6c1630 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -59,6 +59,7 @@ EXTRA_DIST = \ CURL-DISABLE.md \ DEPRECATE.md \ DYNBUF.md \ + EARLY-RELEASE.md \ EXPERIMENTAL.md \ FAQ \ FEATURES.md \