Re: Release Candidates - was Help us out in the curl project

From: Timothe Litt <litt_at_acm.org>
Date: Thu, 6 Feb 2025 06:41:12 -0500

On 06-Feb-25 03:21, Daniel Stenberg via curl-library wrote:
> On Wed, 5 Feb 2025, Marcel Raad via curl-library wrote:
>
>> I think testing the first daily snapshot after the feature window
>> closes would be ideal, as most possibly breaking changes happen
>> before that.
>
> Agreed,
>
> I had a sitdown at FOSDEM with the good people maintaining curl on
> Debian and with some brainstorming on the topic I think we can start
> easy and do this:
>
> 1. I create an official release candidate one (rc1) when we enter
> feature freeze. It would be the first tarball we would appreciate if
> people tested to make sure no regressions or other sillyness have
> crept in. No git tag will be set for this.
>
> It will then be hosted somewhere for a few weeks until removed again.
>
> 2. I create a second release candidate (rc2) two weeks before the
> expected release date the exact same way as the rc1. This will contain
> more fixes, but if anyone finds problems in this there is still some
> time left in the cycle to fix things before the release.
>
> This is a low maintenance take and does not impose hard work on
> anyone. It offers a unified take and offer some snapshots and times
> where extra testing is encouraged.
>
> My plan is to start with this in this release cycle.
>
Release candidates are a good idea, and this is a good approach to the
timing.

However, introducing them raises the issue of how to identify the
version that one has.

Typically, projects add something like "rc1" to the version string. 
curl has never done that, but there are scripts that parse its version. 
e.g. from one widely-distributed script, a few instances:

_CURL_VERSION="$(curl -V | head -1 | cut -d' ' -f2 )"
if check_version "${_CURL_VERSION}" "7.67" ; then
     _NOMETER="--no-progress-meter"
fi

if check_version "${_CURL_VERSION}" "7.20" ; then
     _CURL_SSL_REQD="--ssl-reqd"
else
     _CURL_SSL_REQD="--ftp-ssl-reqd"
fi

  if check_version "${_CURL_VERSION}" "7.33" ; then
     CURL="$CURL --http1.1 "
   fi

This particular script is pretty careful to numerically compare each
version component, but would break with 8.4.3rc1, though happy with
8.4.3.1.

How many scripts would break (especially the less careful ones that
might do full string compares) is unknown, but non-zero.

In any case, it will be important to know what version is reporting an
issue - regardless of what the user thinks.  (Think PATH in a cron job,
or..).

I think that the most likely NOT to break version strings would be a
scheme like

8.13.1.$rc - where $rc is numeric.  Whether to make it a large number
(e.g. 9999) at release, or drop it both have pitfalls.

Dropping it is perfectly compatible with current version numbers, and
won't break existing scripts.  But checking for "changed in RC1" becomes
difficult.  Leaving the extra field risks breaking scripts that don't
expect it.

But since the binary version number (e.x. 0x080c01 in CURLVERSION_*) is
right-justified, it's not easy to do the same transparently for API
users.  Perhaps split the "patch" field into "patch" and "RC" nibbles? 
(so 8.12.1rc2 would be 0x080c12)

One alternative that sidesteps some of these issues would be to add
"RC$rc" to the Features list in release candidates and leave the version
string and symbols alone.  This would display with --version, and be
accessible via the curl_version_info API.

Or, simply bump the patch # with each rc - e.g. .0 = rc1, .1 = rc2, and
going forward, the minimum production release would be patch level 2. 
Not as clear to outsiders ("where did .0 and .1 go?"  and determining if
it's a RC or production release is not obvious).  But perhaps the most
backward-compatible.

There are other options.  But you need to pick and document one.

Whatever scheme is chosen, https://curl.se/docs/versions.html,
https://curl.se/libcurl/c/curl_version.html,
https://curl.se/libcurl/c/symbols-in-versions.html, and
https://curl.se/libcurl/c/curl_version_info.html will need to be updated.

Of course, there needs to be a git tag for each.

It's the "little" things that make trouble...

P.S. While it's hard to imagine RC >=10 for curl - I'd be careful not to
assume a single digit.  Most things that "can't happen" eventually do.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2025-02-06