search

jedisct1 / libsodium

A modern, portable, easy to use crypto library.
https://libsodium.org
Other
12.06k stars 1.72k forks source link

1.0.19 mistagged? #1373

Closed vt-alt closed 1 month ago

vt-alt commented 1 month ago

While updating libsodium package for ALT, I noticed this:

+ git fetch origin --tags
...
 ! [rejected]          1.0.19         -> 1.0.19  (would clobber existing tag)
 * [new tag]           1.0.20         -> 1.0.20
 * [new tag]           1.0.20-RELEASE -> 1.0.20-RELEASE

After --force the 1.0.19 tag is now at 2024-05-25. Previously it was pointing to the same commit as 1.0.19-RELEASE (at 2023-09-13).

Or there is different meaning to 1.0.19 tag?

LilyWangLL commented 1 month ago

In actual use, do we need to prioritize using the 1.0.x-RELEASE version? Is this version more stable than version 1.0.x?

jedisct1 commented 1 month ago

1.0.18 got tagged. This corresponds to the tarballs labeled 1.0.18, and to the 1.0.18-RELEASE tag.

That release tag didn't get any updates. It's done and immutable. It just represents how it was when it the version was changed to 1.0.18.

During the entire lifetime of version 1.0.18, minor bug fixes, optimizations, compatibility issues, etc. were available in the stable branch, and in the 1.0.18-stable tarballs. These changes come with a stability guarantee. The APIs and documented behaviors don't change. So, if your application uses libsodium 1.0.18, you get something constantly and actively supported, and don't have to wait for 1.0.19 that can introduce incompatibilities and bugs due to new features.

Later, version 1.0.19 was tagged, starting a new cycle. The stable branch became the constantly-updated version 1.0.19. The 1.0.18 (not 1.0.18-RELEASE) tag was set to the last stable 1.0.18 version. So, if your application depends on 1.0.18 and you can't update to 1.0.19 for some reason, you can use this. It's unlikely to be change, as the 1.0.18 support cycle is over. But if an important security issue affecting 1.0.18 is ever found, the 1.0.18 tag will be updated to include that fix.

So, 1.0.19 was tagged. The 1.0.19-RELEASE tag represents the state it was at the day of the release. During its life cycle, 1.0.19 also got constant updates in stable branch (and the 1.0.19-stable tarballs).

Recently, a new cycle started with the RELEASE-1.0.20 tag. stable now represents version 1.0.20 with minor fixes and improvements (but no breaking changes nor new features). And since a new cycle started, tag 1.0.19 represents the last stable 1.0.19 version, identical to the last 1.0.19-stable tarball. If your application requires 1.0.19 and can't use 1.0.20, you can use this instead of 1.0.19-RELEASE. It will, for example, ensure that it can be compiled with recent compiler versions while 1.0.19 as originally release can't.

You can stick to the -RELEASE tags if you want. Or use stable to always get the latest release with backported fixes and improvements before the next point release.

Or if you have to use an old version, you can choose to use the non-release tag (or the -stable tarballs of that old version) to get that version with all the fixes that went in before the cycle of the following version started.

dg0yt commented 1 month ago

The moving tags (used like a branch) are quite confusing, and difficult to carry through different trackers. If 1.0.19.2 was a tag, there would be a clear indication that it is between 1.0.19 and 1.0.20.
If 1.0.19 was a branch, there would be a clear indication that it is moving. But it would still be a trap.

A: "libsodium has an important security fix in 1.0.19. Do we already use it?"
B: "Let me check.... yes, we do." A: "Thanks, so we are safe."
But actually A and B use RELEASE-1.0.19 which lacks the important security fix which was added in the pseudo-branch tagged 1.0.19...

jedisct1 commented 1 month ago

Stick to point releases, this is fine. Continuous fixes of every release is a time-consuming service that is hopefully useful to some users, but that you can ignore. Tarballs may also be less confusing than git tags and branches.