marieALaporte
commented
3 years ago @alanorth related to this discussion, I created a DOI for the repo using Zenodo. I thus made a release of the repo with a v2 tag. But that can change in the future.
Open alanorth opened 3 years ago
marieALaporte
commented
3 years ago @alanorth related to this discussion, I created a DOI for the repo using Zenodo. I thus made a release of the repo with a v2 tag. But that can change in the future.
alanorth
commented
3 years ago Oh yes, I just saw that message. That's good!
We should definitely keep using the GitHub commit, issue, pull request, and version tagging workflow as well. We can use semantic versioning where the numbers are like Major.Minor.Patch. Perhaps we only need Major.Minor actually. Then we use the same number in the repository and URL to keep past versions accessible.
For example, every time we make a tagged new version we make a directory in the repository and copy the docs and examples there. They will be available in the GitHub pages (or wherever we host it in the future) automatically.
alanorth
commented
3 years ago I just looked at how Dublin Core does it (see release history). Basically, the current version is always:
And past versions are accessible at a predictable URL using the date of the revision (ours will be version numbers):
Also, purl.org links—in the RDF, for example—always point to the latest version, though we can actually even use versions in the URL!
So for us I think this could look something like this, current version:
Past version:
This works!
Having now gone through several betas, the current v2, and future v2.1 etc, we should think about keeping a public version of the old iterations of the recommendation available. We could use the version number itself or a date (as dcterms does):
It could be as simple as creating a directory in the git repository whenever we move to a new version. We could add a dropdown in the documentation to switch between them.