curl / Mailing Lists / curl-library / Single Mail
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: A quick follow-up release next week

From: Daniel Stenberg via curl-library <>
Date: Sat, 25 May 2019 11:40:56 +0200 (CEST)

On Sat, 25 May 2019, Ray Satiro wrote:

> I prefer either of A) branch off and revert; or D) revert in master. My
> suggestion is if you are going to revert then roll them up into 1 like I did
> rather than have 5 reverts. I think it's clearer that way if you're reading
> the history to see what happened and why.

Good advice I think. Let's see if someone else weighs in as well.

After your input I think I'm on (D) now to make the git history easier to

> To be clear I'm not suggesting wait a week before a patch release I'm
> suggesting wait a week without any major reported problem in the latest
> release before you open the feature window. Each time a release goes out
> --including a patch release-- reset again.

I hear you. My minor variation of that was to suggest that we can have a week
post-release as a rule and allow us to overrule the full week with a public
message saying the feature window has opened again - should we feel that need.

Should we then extend the feature period one week at the far end so that it
remains four weeks or should we narrow it down to 3:5 ? I'm rather indifferent
and can think of reasons for either way.

> For reference I read the last 5 years of release tags [1] and urgent patches
> have typically been within 5-10 days with just one at 2 days.

This is a subject I've brought up on curl up every year so far. The graph I've
shown has been "days between curl releases" and the latest version I've shown
looks like this:

It shows a clear improvement since about a year back as we've done much fewer
"panic releases" (follow-up releases within a short period of time from the
previos release) recently. I credit this enhancement primarily to our extended
use of CI builds which nowadays makes us land much better commits with fewer
follow-up needs. It has however been made clear that the CI builds aren't
covering all the setups that our user base is using - a number of issues
showed up this time around in build combos and setups that we simple didn't
test prior to release. More test coverage and more CI builds can help here.

  / | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
Received on 2019-05-25