Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss the Coq Platform naming scheme having the multiple package pick concept in mind #66

Open
MSoegtropIMC opened this issue Oct 10, 2022 · 1 comment

Comments

@MSoegtropIMC
Copy link

The Coq Platform naming scheme suggested in (https://github.com/coq/ceps/blob/master/text/052-platform-release-cycle.md#platform) was concluded on before Coq Platform supported several picks in one release. This development requires to discuss the naming again.

Currently a specific delivery of Coq - say via a Windows installer - has 3 version components:

  • the version of the Coq Platform release, e.g. 2022.09.0
  • the version of Coq - e.g. 8.16. I leave away the minor version of Coq here
  • the version of the package pick for the version of Coq, e.g. 2022.09+beta1 (currently named 2922.09~beta1)

It is common that there are two package picks for one version of Coq - the one with which this version of Coq was originally released, and one which is as close as possible to the initial package pick of the next release of Coq. The idea behind this is to make it possible to first update the package pick and then the version of Coq for own developments. In my experience it depends on the project and the changes in Coq what is easier.

It is also so that all older versions of Coq (since Coq Platform exists), including the above two package picks - are re-released with each release of Coq Platform. What changes here are OS compatibility fixes and possibly Coq fixes. E.g. one could with Coq Platform 2022.09 build an MacOS installer for Coq 8.14, which is compatible with MacOS 10.13 - the original installer required 10.15 or so. Or there was a change in the C standard library in Ubuntu in 20.04 which made older OCaml incompatible with it. But from a Coq usage point of view, say in the view of reproduction of research artifacts, such a rerelease should behave identical to the original release - it just has somehow extended operating system support. Also pure bug fix releases of Coq are typically have the same combination of Coq+package pick version, since they should be 100% compatible - only the Coq Platform release changes (say from 2022.09.0 to 2022.09.1 ot maybe something completely different if the fix is done much later than the original release as e.g. in the case of the OCaml C library issue.

The main question is, if the current naming like

Coq-Platform-release-2022.09.0-version~8.16~2022.09~beta1-Windows-x86_64.exe

for an installer is appropriate, or if we can come up with a better naming scheme.

@gares
Copy link
Member

gares commented Oct 10, 2022

I think it is fine, but I have "readability issues". This is longer, but a bit more readable, IMO:
Coq-Platform-2022.09.0__core-8.16__pick-2022.09~beta1__os-Windows-x86_64.exe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants