mirror of
https://github.com/curl/curl.git
synced 2024-11-27 05:50:21 +08:00
67 lines
2.7 KiB
Markdown
67 lines
2.7 KiB
Markdown
|
# 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.
|