CPS "releases" should be tagged
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
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.
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.)
- Dominant language
- Python
- Stars
- 191
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cps-org/cps
-
Spec: `c-runtime-vendor` field also should document the "musl" typical value and "bionic"Possibly taken @leha-bot claimed this 1 day ago. Open
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 40/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
Path subtraction removes repeated suffix characters instead of one suffixPossibly taken @Gwerdonatus claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
joke2k/django-environ#671 ·
-
good first issue help wanted windows
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
-
test_pgbouncer deploys the server under test from Charmhub instead of the local build (track/1.31)Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
canonical/temporal-k8s-operator#195 · 1 comment ·
Maintainers usually reply within 4 days
-
`burr` fails to start when the Python path has a space in itPossibly taken @enekoreto claimed this today. Openstatus/needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 5 days
-
device support request
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
zigpy/zha-device-handlers#5461 ·
Maintainers usually reply within 4 days