Consider using an auto-tag release bot

[jcbhmr]

Currently tags seem to be aiming for a Docker-image like (that's the best analogy I can think of) tag system where for each version, there's like a major tag, a minor tag, and a patch tag.

So like v1.5.10 has:

• v1.5.10
• v1.5 => v1.5.10
• v1 => v1.5.10

And then when v1.5.11 comes out, it updates:

• v1 => v1.5.11
• v1.5 => v1.5.11
• v1.5.10 (stays pointing to pinned version)

And similarly, when v1.6.0 comes out:

• v1 => v1.6.0
• v1.5 => v1.5.11
• v1.6 => v1.6.0
• v1.6.0
• v1.5.11
• v1.5.10

At least I think that's what you're going for? It looks like the official GitHub actions use this technique: https://github.com/actions/checkout/tags

Here's a GitHub workflow action that might help automate this: https://github.com/actions/publish-action I know I know it's still in beta, but it is actively being used by GitHub's official actions (and others)! https://github.com/actions/publish-action/network/dependents And you can pin it to a specific commit if you don't want to get skewered by version bumps.

[jcbhmr]

Here's a live example code snippet: https://github.com/actions/setup-node/blob/10f562350248c03b1290d1d8a055102c0da3bebf/.github/workflows/release-new-action-version.yml#L25

    steps:
      - name: Update the ${{ env.TAG_NAME }} tag
        uses: actions/publish-action@v0.2.2
        with:
          source-tag: ${{ env.TAG_NAME }}
          slack-webhook: ${{ secrets.SLACK_WEBHOOK }}

here's a code search link to all the official workflows that use actions/publish-action https://github.com/search?q=org%3Aactions+actions%2Fpublish-action+path%3A**%2Fworkflows%2F**&type=code

[spenserblack]

At least I think that's what you're going for?

Yup, you've got it right! It's used in several different actions repos, and I like it because it allows the user to use the latest, non-breaking version instead of getting pinned to a specific version.

The only different is that I'm not going to do (at least not manually 😆) v1.5, etc.

Here's the basic formula I'm currently doing:
For 0.MAJOR.MINOR, have a 0.MAJOR tag that targets the maximum MINOR release, and, for MAJOR.MINOR.PATCH where MAJOR >= 1, have a MAJOR tag that targets the maximum MINOR.PATCH release (I probably won't backport any patches/bugfixes to prior minor releases). Hope that clarifies my thought process.

I'll have to look into that action, but it sounds cool. But, given my current workflow (I like to write release notes in the git tag to make them a bit more accessible), it might not save too much time 🙂
I might modify this script to abbreviate the tag for me.

[jcbhmr]

Yup, you've got it right! It's used in several different actions repos, and I like it because it allows the user to use the latest, non-breaking version instead of getting pinned to a specific version.

The only different is that I'm not going to do (at least not manually 😆) v1.5, etc.

Yep, I figured as much. Just making sure 👍 this seems to be the convention in github actions is to tag all versions with an additional major (and possibly minor?) tag that tracks along releases in a range.

kinda like npm's "typescript": "^4.5.1" that matches all 4.*.* versions above 4.5.1 and whatever. It's the GitHub Actions' ecosystem equivalent.

Here's the basic formula I'm currently doing: For 0.MAJOR.MINOR, have a 0.MAJOR tag that targets the maximum MINOR release, and, for MAJOR.MINOR.PATCH where MAJOR >= 1, have a MAJOR tag that targets the maximum MINOR.PATCH release (I probably won't backport any patches/bugfixes to prior minor releases). Hope that clarifies my thought process.

i don't fully follow this part, but that's ok. as long as there is v1 v2 v3 and v1.1.0 and v2.5.6 ; those are the two main types i've seen used and provided most often. I think you have that?

---

I'll have to look into that action, but it sounds cool. But, given my current workflow (I like to write release notes in the git tag to make them a bit more accessible), it might not save too much time 🙂

I don't think it matters how the release gets published; it should still trigger the action. Then you just pipe in the tag, and it takes care of mapping it to the major version. #15

I would expect that as long as you publish a release based on a tag named vN.N.N that it'll work flawlessly. however you create that release is totally up to you and your workflow. use the gh cli, use the raw curl api.github.com, use the gui, and it'll all just work hopefully

[spenserblack]

i don't fully follow this part, but that's ok

Yeah I was kind of worried that I was making things more confusing instead of less 😆
But I think you got the gist. It was a very wordy way of saying I'm basically going to replicate NPM's ^x.y.z, but not ~x.y.z.

I don't think it matters how the release gets published; it should still trigger the action.

What I'm getting at, is that, if I'm already manually creating one tag, it's not too much work for me to create 2 🙂

This isn't an argument against the action, just clarifying the weight of the "pros" of the action.

[jcbhmr]

This isn't an argument against the action, just clarifying the weight of the "pros" of the action.

❤

sounds like this is a good idea worth at least investigating 👍

[jcbhmr]

I think this is the easiest change to merge with little-to-no conflict. As long as it doesn't interfere with your workflow? #15