Tested looks good

python3 -m pip install git+https://github.com/shenxianpeng/cpp-linter-action@v1.4.2
gitpod /workspace/cpp-linter-action (update-readme) $ pip3 show cpp-linter
Name: cpp-linter
Version: 1.4.2
Summary: Bootstrapper for docker's ENTRYPOINT executable.
Home-page: https://github.com/2bndy5/cpp-linter-action
Author: Brendan Doherty
Author-email: 2bndy5@gmail.com
License: MIT
Location: /home/gitpod/.pyenv/versions/3.8.13/lib/python3.8/site-packages
Requires: pyyaml, requests
Required-by: 

Note: I created tag v1.4.2 from update-readme branch for testing, so it's a pre-release. I'll recreate the same tag and release if this PR is merged to the master branch

I'm curious if using @v1 will allow us to only require future changes when bumping the major version.

According to the github docs, using v1 can be shorthand for v1.x.x. I think this means we would have to keep moving a separate tag named v1 to the latest released commit (which is currently tagged with v1.4.2). This would be easier than updating the README for every release.

I think this means we would have to keep moving a separate tag named v1 to the latest released commit

Or we could create a branch named v1 and keep pushing deployment-ready commits to that branch (likely cherry-picked from master). But this seem like a bit more work than moving a tag around.

The current version in setup.py is incorrect, it is 1.3.1

Ideally we wouldn't need to keep updating this in setup.py if we use the setuptools_scm lib as a build dependency. However, I neglected to do this since it adds to the action setup time (setuptools_scm is only available via pip).

Alternatively, we could upload a wheel to pypi under the package name cpp-linter-action. This would allow for quicker pip installs, but using setuptools_scm would still affect the action setup (when using a docker on ubuntu runners)

From the tests you run, v1 makes a lot of sense, and it also works with python3 -m pip install git+https://github.com/shenxianpeng/cpp-linter-action@v1

If every release needs to build and upload a wheel to be published to pypi seems to add a bit more work.

Kudos, SonarCloud Quality Gate passed! Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

If every release needs to build and upload a wheel to be published to pypi seems to add a bit more work.

I can easily automate this with CD workflow, but I'm not sure it is worth it right now. Maybe in the future when we have patched in support for other CI services...

To save setup time or add a CI workflow for this? Yes, maybe in the future ...

To save setup time

Recent tests (on the test repo) show that pip installing from the repo directly (instead of pypi) only takes about 12 seconds. So, I'm not sure how much time it would actually save (I'm guessing around 5 seconds).

If you're ready to merge, I can move around the tags afterward (and remove the "pre-release" flag).

5 seconds sounds good! OK, I. am going to merge

FYI, I had to

1. delete the tags
2. push the changes
3. re-create the tags
4. push the changes again

I think this is why the pre-release description of v1.4.2 got removed. BTW, having the tags on a branch that was not the master branch proved to be an additional obstacle.

I did

• deleted the pre-release
• recreate a release v1.4.2 using the tag you created.

I added v1.4.2 to the update-readme branch for testing, it really cause some inconvenience.

oh! In the future, I'll leave the releases in your capable hands.

No problem, I am a release engineer in my other capacity 😆