CPS "releases" should be tagged
- Dominant language
- Python
- Stars
- 191
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Description
Right now, there is no easy way to determine what CPS "was" as of a certain version. (This is also a bit fuzzy, since we haven't always remembered to bump version numbers, and not all changes to the repo modify the version number.)
Still, it would be good if we had *some* sort of tag system. For a first pass, every commit that changes the version number should get a tag that matches the new version number.
Moreover, this seems like a fine candidate for something that can be automated in a GHA.
Community contributions for such a feature/workflow/GHA would be welcomed. (Ideally it should scan from the newest tag to HEAD and tag all version changes identified, such that the first run can bootstrap the backlog of non-existing tags. To facilitate this, especially as 0.5 was the first version to have a `conf.py`, that version has now been tagged.)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by examining conf.py and the repository history to determine how version-number changes can be identified, then review the GitHub Actions workflow configuration. The automation should scan from the newest tag to HEAD and create tags matching each changed version, including tags needed to bootstrap older versions. Done means version-changing commits are discoverable through the expected tags and the workflow can perform the initial backlog scan.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github-actions, python
- Domain
- ci-cd, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100