1.0.17 was touched on download.libsodium.org

[kpp]

​Version 1.0.17 was released on January 7, 2019 however it was modified on 03-Apr-2019. Why?

Linked issue: https://github.com/sodiumoxide/sodiumoxide/issues/326

[jedisct1]

Precompiled libraries are from the 1.0.17-stable so they are updated from time to time.

Visual Studio 2019 is now supported, so new Windows precompiled libraries had to be made.

[kpp]

Please reopen the issue.

Precompiled libraries are from the 1.0.17-stable so they are updated from time to time.

Then upload them to libsodium-latest-stable-...$target.$archive. Why do you think it is OK to touch already released binaries?

[tancred]

If you have suggestions for improvements, please maintain a respectful and gentle tone.

It is entirely up to Frank Denis as the maintainer of this free and open source project to decide how and when to release binaries.

[kpp]

@tancred take a look at https://semver.org/#spec-item-3

3. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

And pushing a binary with modifications under the same version is a violation of this rule. There is a divergence between what is released in https://github.com/jedisct1/libsodium/releases/tag/1.0.17 and what is uploaded as a "latest" 1.0.17.

[tancred]

And pushing a binary with modifications under the same version is a violation of this rule. There is a divergence between what is released in https://github.com/jedisct1/libsodium/releases/tag/1.0.17 and what is uploaded as a "latest" 1.0.17.

So, this project doesn't follow semver and its maintainer gave you a reason why.

I don't think your question is unreasonable, but when you ask "Why do you think it is OK to ..." you imply that the creator and maintainer of this project somehow is not allowed to do what he pleases with it.

You will have more success in your endevours if you ask nicely.

[kpp]

Stop being a bully and let the maintainer answer my questions.

but when you ask

When I ask I ask. Don't put your words into my mouth.

[jedisct1]

The recommended version to use is stable.

Pre-compiled packages are from the recommended version, although I don't always rebuild them as often as needed.

Download should be verified using Minisign or GPG signatures. They are available for all the files available for download. The public keys can be found in the documentation: https://download.libsodium.org/doc/installation#stable-branch

This includes the pre-compiled Windows libraries.

[jedisct1]

Please note that there are never functional changes between a point release and stable patches.

stable additions only improve portability, documentation, or backport harmless optimizations, but the behavior is not changed.

In this case, a new addition to the stable branch was necessary to add support for the just-released Visual Studio 2019. So that people can use this compiler without waiting for months for a new point release.

Sticking to point releases is perfectly fine. If a security issue had to be addressed, a new point release would be immediately made.

But pre-compiled binaries are not stuck to point releases. The MSVC2019 issue perfectly illustrates why I sometimes need to take the time to update them. And to verify them, use signatures as documented.

[kpp]

Hm.

stable additions only improve portability, documentation, or backport harmless optimizations, but the behavior is not changed.

Still it sounds like a patch in terms of semver.

In this case, a new addition to the stable branch was necessary to add support for the just-released Visual Studio 2019. So that people can use this compiler without waiting for months for a new point release.

Does it mean it is a unique situation or do we have to keep it in mind and assume the latest pre-built binaries can change time to time and take actions?

[kpp]

Actually I don't mind to build libsodium from source from stable branch but is there a "universal" script for that?

[jedisct1]

Binaries for mingw are built using dist-build/msys2-mingw32.sh and dist-build/msys2-mingw64.sh.

[kpp]

Yes that's easy. How about a script for windows to build it from cmd autodetecting MSVS version?

[Erk-]

It looks like it have happened again, is there anywhere where you give the reason for it? @jedisct1

[jedisct1]

@Erk- https://download.libsodium.org/libsodium/releases/README.html