docs/EARLY-RELEASE.md: how to determine an early release

[bagder]

URL: https://curl.se/mail/lib-2022-10/0079.html

[rodwiddowson]

I missed the mail conversation until now but I think there may be another question - which I apply when weighing up these issues.
Is rolling back to the previous release an acceptable workaound for affected users?

Obviously there are many cases when it isn't. like "The affected release carried a fix for a Security Advisory" or "This bug is a security issue and may go unnoticed".

In the specific case I would have thought that waiting until Tuesday before cranking a release might be prudent....

[danielgustafsson]

.. or "This bug is a security issue and may go unnoticed".

For bugs that are found to be security issues I think the security process already has wording around that. If we feel that's not giving enough direction I think we should address that there instead.

[rodwiddowson]

For bugs that are found to be security issues I think the security process already has wording ..

Agreed 110%

[bagder]

I missed the mail conversation until now but I think there may be another question - which I apply when weighing up these issues. Is rolling back to the previous release an acceptable workaound for affected users?

I phrased it like this in the current draft:

• Can affected users safely rather revert to a former release until the next scheduled release?

Obviously there are many cases when it isn't. like "The affected release carried a fix for a Security Advisory" or "This bug is a security issue and may go unnoticed".

Right. Like our current situation: we shipped 7.86.0 with fixes for four security related problems. Asking users to stick to the former release due to the existence of a problem in the new release might then implicitly ask them to live with those four security problems for another release cycle ... Not necessarily the most responsible way.

In the specific case I would have thought that waiting until Tuesday before cranking a release might be prudent....

I went into scheduling a little bit in the bottom for the cases we actually deem an early release to be the right choice. It is also important to not rush out releases to make sure things are always done in an orderly way and that all procedures are followed.

[henning-schild]

Great to see how you guys deal with all of that and thanks so much!

The breakage can be seen as severe and security relevant on its own. Any machine in a network with proxies will potentially/partially loose network connectivity after installing that affected release. Which is clearly related to the A in CIA.

Maybe people could even get stuck on a broken release. Because their package manager is based on curl and their repo mirror based on no_proxy. Would require some package sideloading tricks to get back to live.

[henning-schild]

Maybe someone could ping the maintainers of alpine and arch linux. They should know what is going on. And they might have their own opinion on how they would want to deal with it.

But others should also know to maybe avoid that release.

[bagder]

Maybe someone could ping the maintainers of alpine and arch linux.

There are bugs in every curl release. I presume distro maintainers have ways to deal with that.

[bagder]

Surely this should not have the hacktoberfest-accepted tag set?