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: Version 8 at 25 years
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 2 Sep 2021 08:09:15 -0400
On 02-Sep-21 07:22, Daniel Stenberg via curl-library wrote:
>
> 2. We call that release 8.0.0
>
> ... completely independently of what version we released immediately
> before then and disregarding what we add or not in that release. We've
> been ever-incresing the minor version number since the year 2000, and
> I've been struggling to figure out how to avoid us reaching 100 and
> thereby possible cause confusion among users.
>
> I don't want to bump the soname or change any compatiblity or APIs
> because of this. I just want us to work with smaller numbers for a
> while. I hope that one of the benefits with bumping the major number
> is that everyone who sticks with version 7 will rather soon feel
> outdated.
Bumping to version 8 gives you the opportunity to go to a padded 3-digit
minor version number; e.g. 8.000.0.
That would avoid the "100" issue in another 22 years. I've seen more
than one script that does a string or floating
compare on version.
Note that the same issue arises with "10" - e.g. 8.10.0 is < 8.9.0 as a
string or as a decimal.
Yes, such scripts are technically "broken" (a proper version compare
splits on '.' and compares
each component separately as an integer) - but if you worry about 100
causing confusion, why not be proactive?
e.g. from one such widely-distributed bash script:
_CURL_VERSION="$(curl -V | head -1 | cut -d' ' -f2 )"
# shellcheck disable=SC2072
if [[ ! "${_CURL_VERSION}" < "7.67" ]]; then
_NOMETER="--no-progress-meter"
fi
if [[ ! "${_CURL_VERSION}" < "7.33" ]]; then
CURL="$CURL --http1.1 "
fi
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Date: Thu, 2 Sep 2021 08:09:15 -0400
On 02-Sep-21 07:22, Daniel Stenberg via curl-library wrote:
>
> 2. We call that release 8.0.0
>
> ... completely independently of what version we released immediately
> before then and disregarding what we add or not in that release. We've
> been ever-incresing the minor version number since the year 2000, and
> I've been struggling to figure out how to avoid us reaching 100 and
> thereby possible cause confusion among users.
>
> I don't want to bump the soname or change any compatiblity or APIs
> because of this. I just want us to work with smaller numbers for a
> while. I hope that one of the benefits with bumping the major number
> is that everyone who sticks with version 7 will rather soon feel
> outdated.
Bumping to version 8 gives you the opportunity to go to a padded 3-digit
minor version number; e.g. 8.000.0.
That would avoid the "100" issue in another 22 years. I've seen more
than one script that does a string or floating
compare on version.
Note that the same issue arises with "10" - e.g. 8.10.0 is < 8.9.0 as a
string or as a decimal.
Yes, such scripts are technically "broken" (a proper version compare
splits on '.' and compares
each component separately as an integer) - but if you worry about 100
causing confusion, why not be proactive?
e.g. from one such widely-distributed bash script:
_CURL_VERSION="$(curl -V | head -1 | cut -d' ' -f2 )"
# shellcheck disable=SC2072
if [[ ! "${_CURL_VERSION}" < "7.67" ]]; then
_NOMETER="--no-progress-meter"
fi
if [[ ! "${_CURL_VERSION}" < "7.33" ]]; then
CURL="$CURL --http1.1 "
fi
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/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-09-02