GMLC-TDC
Make release names consistent
Currently these are the names for the releases:
Helics-2.5.0-Linux-x86_64.tar.gzHelics-2.5.0-macOS-x86_64.zipHelics-2.5.0-msvc2017-win64.zipHelics-2.5.0-msvc2019-win64.zipHelics-2.5.0-win32.zipHelics-2.5.0-win64.exeHelics-2.5.0-win64.zipHelics-shared-2.5.0-Linux-x86_64.tar.gzHelics-shared-2.5.0-macOS-x86_64.tar.gzHelics-shared-2.5.0-win32.tar.gzHelics-shared-2.5.0-win64.tar.gzHelics-v2.5.0-source.tar.gz
Helicsshould be eitherhelicsorHELICS.- We use
Linux,macOS,win32,win64. They should all be lowercase. - I think every tar file / zip file should have the compiler and the version in the name (gcc7, clang8 etc).
x86_64should be used for 64 bit builds,i386should be used for 32 bit builds.- The difference between
Helics-2.5.0-win64.zipandHelics-2.5.0-msvc2019-win64.zipis not obvious.
It's currently hard to programmatically download the appropriate build for a operating system.
Right now the naming is similar to https://cmake.org/download/ and PyPI wheels.
I think some name changes were brought up before, but we didn't want to change it because it didn't match earlier releases.
1 & 2: Making it all lowercase would look nice enough.
3: I think that would create an impression that they depend on having a particular compiler+version, which most of them don't.
4: I think for 32-bit builds it would be safer using i686 like PyPI. I'm not sure if we can guarantee i386 compatibility. Or we could follow the CMake naming and use the generic x86 (this only really applies to the Windows builds).
5: The msvc releases have a pre-compiled C++ shared library, which requires using the same compiler+version as it was compiled with. The challenge with the C++ shared library (on Linux/macOS/mingw) is that compatibility can be affected by the compiler version and flags used, which creates a large build matrix for releases, and potential for users encountering issues that are easier to resolve by having them start with the C++ shared library getting compiled on their system with whatever compiler they are building other tools with.
Would moving the msvc part to the end of the name make it clearer? For programmatic builds, the msvc builds can be treated as if they don't exist; for a user the only time it should matter is if they are building something with msvc that uses the C++ shared library.
If we want to make it similar to cmake downloads, we should use Darwin instead of macOS.
And yes, I think moving the msvc to the end would be nice.
Should we? There are some package recipes that will need updating to handle a split in naming between the changed naming convention and previous names.
If we are breaking the naming convention, should we change helics-shared to helics-sharedlib, or the other ones (other than msvc builds) to helics-apps to reflect when users might want to download each one? There's only so much the name can convey though, so it may be better to leave the explanation of package contents to the install guide.
I guess I would say make any changes that don't break anything now. If there are slight bigger changes that might require some modifications in supporting repos We can make them in 2.6.
And lets consider some larger cases as part of the general renaming discussions as part of HELICS 3
There are two reasons I would like to have consistent names / make breaking changes now:
- People are more likely to go to releases directly on github if they are used to other open source packages, and it should be as clear as possible.
- If someone is programmatically downloading releases, they shouldn't need to special case every operating system, architecture, whether there's a shared library or not, etc.
Target Triplet exist for this reason, and following this convention would solve this problem in the most straightforward standard way. I think should just name releases now using the same convention, even if we have to use unknown right now as part of the triplet.
https://wiki.osdev.org/Target_Triplet
https://wiki.debian.org/Multiarch/Tuples
If they're writing anything cross-platform to download releases, they are likely already going to have special cases to handle different operating systems. Deciding to get the download with just the shared library, or apps+shared library is something that they'd choose based on their use case and should be able to know ahead of time.
From the descriptions, it sounds like the debian multiarch naming (which uses normalized triplets, which seems to get rid of the optional/almost always unknown vendor field) would be a close match to the default vcpkg triplets.
Hopefully we never have to deal with universal macOS binaries, and Apple sticks with intel processors.
With some changes the format would be <helics package>-<helics version>-<architecture>-<platform>.<ext>, which also moves the packages with msvc files down farther, leaving the one that most users visiting the releases page would want near the top of the list.
helics-2.5.0-i686-win32.zip
helics-2.5.0-x86_64-linux-gnu.tar.gz
helics-2.5.0-x86_64-macos.zip
helics-2.5.0-x86_64-win64.exe
helics-2.5.0-x86_64-win64.zip
helics-msvc2017-2.5.0-x86_64-win64.zip
helics-msvc2019-2.5.0-x86_64-win64.zip
helics-shared-2.5.0-i686-win32.tar.gz
helics-shared-2.5.0-x86_64-linux-gnu.tar.gz
helics-shared-2.5.0-x86_64-macos.tar.gz
helics-shared-2.5.0-x86_64-win64.tar.gz
helics-v2.5.0-source.tar.gz
We'll make the changes for the 2.6 release, since it will require updating package recipes/scripts in a few places.