Issue
Currently, our process of maintaining the major release tags is as follows:
- We create a PR with the necessary changes.
- We merge the PR.
- We create a new release with a new tag to publish in the marketplace.
- We move the major release tag to point to the latest release i.e
# 1 indicates the major release tag
git tag -f 1 <latest_release_tag>
Our current process
- doesn't follow GitHub recommended practice. GitHub encourages creating a release branch i.e
release/v1 before creating the release tag i.e v1.0.2
- manually updating the major release tag might result in human errors like forgetting to update it.
Solution
In order to follow the GitHub recommended practice and reduce the effort of manually updating the release tag, here is what we can do:
- Create a new Release Pull Request: We can create a new PR corresponding to the new release tag we want to publish. We are already following this convention in client projects.
- Create a new GH Workflow for updating Major Release Tag: We can introduce a new GH Action workflow that will trigger right after we create a new release. The workflow will update the major release tag to point to the latest release. Popular Actions like
actions/checkout follow this practice as well. Our workflow file could look like the following:
name: Move Major Release Tag
on:
release:
types: [created]
jobs:
update_major_release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Get the major version num and update the tag
run: |
LATEST_TAG=${{github.ref_name}}
MAJOR_VERSION=${LATEST_TAG%%.*}
# why Hoang? explanation after this
git config user.name 'Hoang Mirs'
git config user.email 'hoang.mirs@gmail.com'
git tag -fa ${MAJOR_VERSION} -m "Update major version tag"
git push origin ${MAJOR_VERSION} --f
Why @hoangmirs's username and email in the action? 😅
Because I can see his email on the security contact email:

Who Benefits?
developers
What's Next?
Resources
Issue
Currently, our process of maintaining the major release tags is as follows:
Our current process
release/v1before creating the release tag i.ev1.0.2Solution
In order to follow the GitHub recommended practice and reduce the effort of manually updating the release tag, here is what we can do:
actions/checkoutfollow this practice as well. Our workflow file could look like the following:Why @hoangmirs's username and email in the action? 😅
Because I can see his email on the security contact email:
Who Benefits?
developers
What's Next?
Resources
actions/checkoutcicirello/jacoco-badge-generator