EARLY-RELEASE.md (2937B)
1 <!-- 2 Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al. 3 4 SPDX-License-Identifier: curl 5 --> 6 7 # How to determine if an early patch release is warranted 8 9 In the curl project we do releases every 8 weeks. Unless we break the cycle 10 and do an early patch release. 11 12 We do frequent releases partly to always have the next release "not too far 13 away". 14 15 ## Bugfix 16 17 During the release cycle, and especially in the beginning of a new cycle (the 18 so-called "cool down" period), there are times when a bug is reported and 19 after it has been subsequently fixed correctly, the question might be asked: 20 is this bug and associated fix important enough for an early patch release? 21 22 The question can only be properly asked when a fix has been created and landed 23 in the git master branch. 24 25 ## Early release 26 27 An early patch release means that we ship a new, complete and full release 28 called `major.minor.patch` where the `patch` part is increased by one since 29 the previous release. A curl release is a curl release. There is no small or 30 big and we never release just a patch. There is only "release". 31 32 ## Questions to ask 33 34 - Is there a security advisory rated high or critical? 35 - Is there a data corruption bug? 36 - Did the bug cause an API/ABI breakage? 37 - Does the problem annoy a significant share of the user population? 38 39 If the answer is yes to one or more of the above, an early release might be 40 warranted. 41 42 More questions to ask ourselves when doing the assessment if the answers to 43 the three ones above are all 'no'. 44 45 - Does the bug cause curl to prematurely terminate? 46 - How common is the affected buggy option/feature/protocol/platform to get 47 used? 48 - How large is the estimated impacted user base? 49 - Does the bug block something crucial for applications or other adoption of 50 curl "out there" ? 51 - Does the bug cause problems for curl developers or others on "the curl 52 team" ? 53 - Is the bug limited to the curl tool only? That might have a smaller impact 54 than a bug also present in libcurl. 55 - Is there a (decent) workaround? 56 - Is it a regression? Is the bug introduced in this release? 57 - Can the bug be fixed "easily" by applying a patch? 58 - Does the bug break the build? Most users do not build curl themselves. 59 - How long is it until the already scheduled next release? 60 - Can affected users safely rather revert to a former release until the next 61 scheduled release? 62 - Is it a performance regression with no functionality side-effects? If so it 63 has to be substantial. 64 65 ## If an early release is deemed necessary 66 67 Unless done for security or similarly important reasons, an early release 68 should not be done within a week of the previous release. 69 70 This, to enable us to collect and bundle more fixes into the same release to 71 make the release more worthwhile for everyone and to allow more time for fixes 72 to settle and things to get tested. Getting a release in shape and done in 73 style is work that should not be rushed.