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

Replication of releases/tags from coq-contribs repository #6

Open
palmskog opened this issue Jul 25, 2019 · 2 comments
Open

Replication of releases/tags from coq-contribs repository #6

palmskog opened this issue Jul 25, 2019 · 2 comments
Assignees

Comments

@palmskog
Copy link
Member

There are several releases and tags in the coq-contribs repos for the project. Ideally, these should be replicated in this repository to allow users of old versions of Coq to have a "one stop shop" for all dblib needs.

@KevOrr KevOrr self-assigned this Aug 7, 2019
@KevOrr
Copy link
Member

KevOrr commented Aug 30, 2019

In coq-contribs/dblib, v8.6.0, v8.7.0 and v.8.8.0 all point to the same commit, which is the tip of master. I also think v8.5.0 is meant to be pointing to the same commit, though it's not.

Are there any guidelines on how to version Coq libraries? I've seen some projects just do semantic versioning and make sure that the same tree builds on all supported versions of Coq, though some others will do something like vX.Y.Z+coqA.B. Currently, dblib builds fine on docker-coq from 8.5 to dev, so I'm not sure that separate releases for different Coq versions are necessary, but I'm new to Coq packaging, so any input would be helpful.

@Zimmi48
Copy link
Member

Zimmi48 commented Nov 25, 2020

There's some guideline here: https://github.com/coq-community/manifesto/wiki/Commit,-branch-and-release-policies
As you noted, the recommended practice for libraries (as opposed to plugins) is to have releases that support several versions at once instead of having one release per Coq version as it has been the practice of coq-contribs maintainers (for uniformity and simplicity).
Unfortunately, former coq-contribs have to bear the weight of past releases, which influence from which version number you can start numbering. E.g., if the last release in the opam archive was 8.8.0, it would be good not to create a new version with a lower number.
Therefore, some former contribs, while adhering to the policy of being compatible with multiple versions at once still use a version number of Coq for their own releases (e.g. the version of Coq the release adds support for).

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

3 participants