I suggest that we start using git tags for releases. A git tag is just a named commit, and so it points to a specific snapshot of the repository. By creating a tag for a release such as v2019-06-07, we can point to the current version of all the code, especially src/ontology. So there would be no need for a separate releases directory that duplicates those files for each release.
The GitHub "Releases" mechanism builds on git tags. GitHub provides a nice page of all the tags that are considered releases, and shows release notes. But git tags are part of git, and not specific to GitHub, so the tags will be maintained if IAO migrates away from GitHub.
Duplicating files in a release directory was standard procedure for Subversion repositories, but is not for git repositories. As far as I can tell, every OBO project on GitHub has adopted the git convention. By thwarting this convention, I believe that duplicating files in repositories is confusing to IAO developers and users.
Here's an example of OBI's releases, showing how each tag points to a specific version of all the files in the repository:
making a v2019-06-07 tag (or something) for the current version of this repository (after the release planned in #215), which includes the releases directory
updating the IAO PURLs to point to their proper files in the v2019-06-07 snapshot
git rm releases to remove the releases directory from the repository going forward -- all those files will still be available by looking at the v2019-06-07 snapshot of the repository (or any previous version of the repository)
adding some links to the previous releases to the README
adding a git tag for each IAO release going forward
zhengj2007
commented
4 years ago
I suggest that we start using git tags for releases. A git tag is just a named commit, and so it points to a specific snapshot of the repository. By creating a tag for a release such as
v2019-06-07, we can point to the current version of all the code, especiallysrc/ontology. So there would be no need for a separatereleasesdirectory that duplicates those files for each release.The GitHub "Releases" mechanism builds on git tags. GitHub provides a nice page of all the tags that are considered releases, and shows release notes. But git tags are part of git, and not specific to GitHub, so the tags will be maintained if IAO migrates away from GitHub.
Duplicating files in a
releasedirectory was standard procedure for Subversion repositories, but is not for git repositories. As far as I can tell, every OBO project on GitHub has adopted the git convention. By thwarting this convention, I believe that duplicating files inrepositoriesis confusing to IAO developers and users.Here's an example of OBI's releases, showing how each tag points to a specific version of all the files in the repository:
https://github.com/obi-ontology/obi/releases
To make this change I suggest:
v2019-06-07tag (or something) for the current version of this repository (after the release planned in #215), which includes thereleasesdirectoryv2019-06-07snapshotgit rm releasesto remove thereleasesdirectory from the repository going forward -- all those files will still be available by looking at thev2019-06-07snapshot of the repository (or any previous version of the repository)