[Question] Can we simplify the naming of the release archive files?

[catatsuy]

Hello, maintainers of the quictls/openssl project,

I have a question regarding the naming convention used for the release files in the quictls/openssl project.

Currently, the names of the release files are somewhat confusing, such as openssl-openssl-3.0.8-quic1.tar.gz. I would like to suggest a more simplified naming convention, similar to what OpenSSL uses for their releases, like openssl-3.1.0.tar.gz.

Would it be possible to change the format to something like quictls-3.0.8.tar.gz? This would make it easier for users who want to automate processes related to the project, as the current naming convention can be cumbersome to work with.

Please let me know your thoughts on this matter, as I believe it would be beneficial to the users of the quictls/openssl project.

Thank you for your time and consideration.

[tmshort]

Versions are based on the labels we use, not sure where openssl-openssl-3.0.8-quic1.tar.gz (i.e. the double openssl) came from. Looking at the releases info, I'm not seeing that. So, I'm guessing that was a typo? Unless your're somehow using package-label? We're basing QuicTLS labeling on the OpenSSL labeling scheme, which puts openssl into the label name. Other than the pre-release suffix that we are using to denote the version of the QuicTLS changes, this shouldn't be different than an OpenSSL release. Could you elaborate?

The problem with quictls-3.0.8.tar.gz is that it doesn't allow us to specify an updated QuicTLS version (that's what the -quic1, -quic2, etc, represents). We would be breaking semantic versioning if we added a 4th digit to the version. Semantic versioning does allow a pre-release suffix starting with -(or build metadata using +), but it also indicates that versions with those pre-release suffixes are less than the numbered version, or ignored. i.e:

1.0.0-alpha < 1.0.0-beta < 1.0.0-rc1 < 1.0.0-rc2 < 1.0.0 < 1.0.1-rc1 < 1.0.1

Thus:

3.0.8-quic1 < 3.0.8-quic2 < 3.0.8

So, technically, the QuicTLS version numbers fall before the OpenSSL versions. 😞 But it allows us to add fixes to QuicTLS without modifying the base OpenSSL version number.

[catatsuy]

In my previous messages, I mentioned that I assumed the release files for quictls/openssl could be obtained from https://github.com/quictls/openssl/releases. However, based on your response, it seems that this might not be the case.

Could you please clarify where we should obtain the release files for quictls/openssl? This information would be very helpful for users who want to download and work with the project.

Thank you for your assistance. @tmshort

[tmshort]

That's where they are; is the link not working for you? We only supply source-code releases now.

[catatsuy]

Thank you for your response.

The link is working, and I am able to access the release files. However, I find that the file names after downloading are somewhat confusing, which makes automation more challenging. Is it possible to provide cleaner file names for the downloaded release files to facilitate easier automation?

Thank you for considering my request.

[richsalz]

Is this still a concern? The QuicTLS filenames should be generated algorithmically, in a deterministic way.

[catatsuy]

Thank you for your response.

I understand your reasons for the current naming scheme, particularly with regards to versioning. However, my concern remains as I find it difficult to handle these files due to their unconventional naming convention compared to projects like OpenSSL and LibreSSL.

[richsalz]

Can you propose a different naming scheme, with some examples?

[catatsuy]

@richsalz I would like the naming convention for the release files of this repository to be the same as OpenSSL's.
When you decompress a file named openssl-3.1.1.tar.gz, it will output a directory with the same name, openssl-3.1.1. The release files of this repository currently do not follow this pattern.

[richsalz]

But QuicTLS does not make tar files. We only distribute things via the source tree here on GitHub.

[catatsuy]

I consider the current release file very tricky to handle. How is the QuicTLS source code expected to be used?

[richsalz]

Where did you find a "release file" ? Please post the link. As for how to use this, you download the source and build it. Just like any other GitHub project.

[catatsuy]

I am talking about the GitHub Release, which is formatted differently than OpenSSL.

https://github.com/quictls/openssl/releases

[richsalz]

Thank you. We are not doing that any more. I have removed the older releases, and will remove the last two shortly. We cannot change the name/repository/directory name. We will make the README more clear about how to use it.

[catatsuy]

Thank you. So you are not expecting me to use GitHub Release and I should use a git clone directly?

[richsalz]

Unless someone wants to volunteer to make releases, that is that I would do, clone the repo. Even if someone does help make releases, the directory issue will not be changed. I am going to close this. See #120 for more discussion.