Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: noproxy breakage
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 28 Oct 2022 09:28:02 +0200 (CEST)
Thanks everyone for your excellent feedback. Combining our collective
thoughts, the text below is what I boiled it down to. There will be no exact
science on how to determine when to do an early release. I also have not yet
figured out my own position on the noproxy bug that prompted me to start this
thread.
# 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 to 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?
## If an early release is deemed necessary
Unless done for security or similarly very important reasons, an early release
should never be done within two weeks of the previous version was shipped.
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.
Date: Fri, 28 Oct 2022 09:28:02 +0200 (CEST)
Thanks everyone for your excellent feedback. Combining our collective
thoughts, the text below is what I boiled it down to. There will be no exact
science on how to determine when to do an early release. I also have not yet
figured out my own position on the noproxy bug that prompted me to start this
thread.
# 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 to 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?
## If an early release is deemed necessary
Unless done for security or similarly very important reasons, an early release
should never be done within two weeks of the previous version was shipped.
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.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-10-28