Version 8.7.1 only in repo tag and tarball name, not in code

[levicki]

I did this

• Cloned repository
• Checked out commit de7b3e8

I expected the following

That the checked out include/curl/curlver.h reflects the repository tag version and version in souce tarball name — it doesn't:

/* This is the version number of the libcurl package from which this header
   file origins: */
#define LIBCURL_VERSION "8.7.0-DEV"

/* The numeric version number is also available "in parts" by using these
   defines: */
#define LIBCURL_VERSION_MAJOR 8
#define LIBCURL_VERSION_MINOR 7
#define LIBCURL_VERSION_PATCH 0

/* This is the numeric version of the libcurl version number, meant for easier
   parsing and comparisons by programs. The LIBCURL_VERSION_NUM define will
   always follow this syntax:

         0xXXYYZZ

   Where XX, YY and ZZ are the main version, release and patch numbers in
   hexadecimal (using 8 bits each). All three numbers are always represented
   using two digits.  1.2 would appear as "0x010200" while version 9.11.7
   appears as "0x090b07".

   This 6-digit (24 bits) hexadecimal number does not show pre-release number,
   and it is always a greater number in a more recent release. It makes
   comparisons with greater than and less than work.

   Note: This define is the full hex number and _does not_ use the
   CURL_VERSION_BITS() macro since curl's own configure script greps for it
   and needs it to contain the full number.
*/
#define LIBCURL_VERSION_NUM 0x080700

curl/libcurl version

curl 8.7.0 (Windows) libcurl/8.7.0 Schannel WinIDN
Release-Date: 2024-03-27
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI threadsafe Unicode UnixSockets

operating system

Microsoft Windows Version 10.0.22631.3447

[levicki]

What I am trying to say is that either the version should have been bumped in the curlver.h as well, or the previous commit should have been amended and force-pushed so that version stays the same with fixed tarballs.

IMO current situation is confusing, because semantic version should apply to code changes, not to build artifacts and artifacts should match the code version, not have their own.

[bagder]

Every curl release ever done has been shipped in a tarball. The contents of that tarball is the release.

A curl release is generated from the source code in git at a specific tag, which is named according to the release.

semantic version should apply to code changes

That's your opinion, not the one we use and stand for in the curl project.

This is not a curl bug. This is just your wrong assumptions.

[levicki]

A curl release is generated from the source code in git at a specific tag, which is named according to the release.

Shouldn't the version in the git tag name and the version in the source match then? If not, why not?

That's your opinion, not the one we use and stand for in the curl project.

Not really my opinion, it's defined here : Semantic Versioning 2.0.0.

Or at least that's how I understand it, but of course my understanding may be incorrect or incomplete hence the request for clarification.

This is not a curl bug. This is just your wrong assumptions.

I never claimed it was a bug, but there's no "Question" issue template to request clarifications.

[bagder]

Shouldn't the version in the git tag name and the version in the source match then? If not, why not?

It's a pointless exercise. Even if we would update the source to have the exact same version in the code as the tag, the contents in git does not match the release tarball because the release tarballs are generated. They contain files not present in git. Because we don't commit generated files.

That's your opinion, not the one we use and stand for in the curl project.

Not really my opinion, it's defined here : Semantic Versioning 2.0.0.

It does not say anything like that. We release "patch versions" when we fix the release. We fixed the 8.7.0 release so we made 8.7.1. We bumped the minor version number because it was a bugfix release. Exactly the way semver explains patch versions should work. Nowhere does it say that only a subset of bugfixes may be counted as bugfixes.

This is not a curl bug. This is just your wrong assumptions.

I never claimed it was a bug, but there's no "Question" issue template to request clarifications.

Yes there was. And since a few minutes back there are even two mentions on how to ask questions.

[levicki]

It's a pointless exercise. Even if we would update the source to have the exact same version in the code as the tag, the contents in git does not match the release tarball because the release tarballs are generated. They contain files not present in git. Because we don't commit generated files.

The reason I am even asking is this — I use a script to build my own binary release of curl from GitHub, and I apply a patch to curlver.h before building to include actual version (without -DEV) and actual release date. My patch file expected 8.7.1-DEV and it got 8.7.0-DEV despite the checked out git tag being 8.7.1 and it of course failed.

I wanted to know whether to expect discrepancies like this in the future so I can adjust my build process accordingly. Hopefully the information you provided will be helpful to others too so thanks I guess.

Nowhere does it say that only a subset of bugfixes may be counted as bugfixes.

It says:

A bug fix is defined as an internal change that fixes incorrect behavior.

AFAIK, only the actual code / API has behavior, not tarballs so if code hasn't changed then the git tag should not have been incremented either (and that's my opinion).

Yes there was. And since a few minutes back there are even two mentions on how to ask questions.

My apologies for not noticing the Discussions tab, if I did I would have opened a discussion instead of creating the issue. I've noticed you moved it so hopefully no harm done.

P.S. My solution to the problem is the exact opposite of what your blog post said — checkout 8.7.0 and pretend that 8.7.1 didn't exist.

[jay]

The DEV version string in the repo is not always bumped immediately.

There may be child commits after the release tag that do not show the next version. For example curl 8.6.0 is based on the commit tagged as curl-8_6_0. That commit has a curlver header with the version string "8.6.0-DEV". Several commits later the version string in curlver is changed to "8.6.1-DEV" since 8.6.0 has been released.

What I think may have confused you is 8.7.0 was released and then 8.7.1 immediately after that. There was never any change to "8.7.1-DEV" after the 8.7.0 release, there was no period of time for that. Instead several commits after 8.7.1 was released the version string was changed from "8.7.0-DEV" to "8.7.2-DEV".

If you really want to be specific about commits consider using git describe:

$ git describe
curl-8_7_1-177-gcf337d8

OTOH if you want to keep it simple and you are only going to check out a release tag instead of using the actual generated release then you could modify the curlver based on that release tag. See checkout-curl-release.pl for example. What you cannot do is expect that the version string in the commit will be the same as in the release tag and just chop off the -DEV suffix from it.

[levicki]

Thanks for the clarification.

I was simply expecting that each release version from the Github Releases page on this repo can be reproduced from the associated git commit (with the minimal change of stripping out -DEV and inserting an actual release date in curlver.h).

As per Daniel's and your comments It seems that's not the case, and that my assumption about build reproducibility was wrong. I will just have to be more careful about it going forward.