Lines Matching +full:ship +full:- +full:to

1 # How to determine if an early patch release is warranted
6 We do frequent releases partly to always have the next release "not too far
12 so-called "cool down" period), there are times when a bug is reported and
21 An early patch release means that we ship a new, complete and full release
26 ## Questions to ask
28  - Is there a security advisory rated high or critical?
29  - Is there a data corruption bug?
30  - Did the bug cause an API/ABI breakage?
31  - Will the problem annoy a significant share of the user population?
33 If the answer is yes to one or more of the above, an early release might be
36 More questions to ask ourselves when doing the assessment if the answers to
39  - Does the bug cause curl to prematurely terminate?
40  - How common is the affected buggy option/feature/protocol/platform to get
42  - How large is the estimated impacted user base?
43  - Does the bug block something crucial for applications or other adoption of
45  - Does the bug cause problems for curl developers or others on "the curl
47  - Is the bug limited to the curl tool only? That might have a smaller impact
49  - Is there a (decent) workaround?
50  - Is it a regression? Is the bug introduced in this release?
51  - Can the bug be fixed "easily" by applying a patch?
52  - Does the bug break the build? Most users do not build curl themselves.
53  - How long is it until the already scheduled next release?
54  - Can affected users safely rather revert to a former release until the next
56  - Is it a performance regression with no functionality side-effects? If so it
57    has to be substantial.
64 This, to enable us to collect and bundle more fixes into the same release to
65 make the release more worthwhile for everyone and to allow more time for fixes
66 to settle and things to get tested. Getting a release in shape and done in