You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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:
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.
The text was updated successfully, but these errors were encountered: