Lines Matching +full:- +full:- +full:no +full:- +full:patch

1 <!--
4 SPDX-License-Identifier: curl
5 -->
7 # How to determine if an early patch release is warranted
10 and do an early patch release.
18 so-called "cool down" period), there are times when a bug is reported and
20 is this bug and associated fix important enough for an early patch release?
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".
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?
43 the three ones above are all 'no'.
45  - Does the bug cause curl to prematurely terminate?
46  - How common is the affected buggy option/feature/protocol/platform to get
48  - How large is the estimated impacted user base?
49  - Does the bug block something crucial for applications or other adoption of
51  - Does the bug cause problems for curl developers or others on "the curl
53  - Is the bug limited to the curl tool only? That might have a smaller impact
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
62  - Is it a performance regression with no functionality side-effects? If so it