Plan for tags and recommended versions after 1.0.0

[stevector]

The current readme recommends consumers of this action pin exact versions like 0.5.1. When I wrote that guidance I assumed that after 1.0.0 we would recommend that customers switch to consuming something like v1 (since that is the convention with common actions like checkout).

However, I did not know that the way checkout accommodates that consumption pattern is by regularly changing the hash to which tags like v4 point. I have a near allergic reaction to ever changing a tag. The behavior I want is for consumers to get the latest tag on a branch and to allow consumers to determine their own specificity. Said another way, I want the specificity and behavior of a composer.json file.

I'll need to think through how to best accommodate that.

[pwtyler]

My recommendation would be to use https://github.com/pantheon-systems/action-autotag and do not think it needs to wait until v1.

[jazzsequence]

The standard convention for actions is for vX to be the latest stable branch of a version that reflects the most recent vX.Y.Z tag. Our current branch strategy (defaulting to 0.x as the main branch) kind of breaks this convention because everything that is merged into 0.x is essentially pre-release code. A better solution is making the default branch be main or dev and using Autotag ☝️ or the release workflow dispatch I created to handle creating the tag and merging the latest development code to the vX branch.