what is the current versioning convention for tags?

[cartazio]

does v1 track most recent 1..? does v1.1 track most recent 1.1.*?

[hazelweakly]

Yes. The idea is that the tags should work like semver. In practice, you should be able to set the action at v1 forever and not worry about it.

The only reason I added the v1.1 tag originally is because it was used to denote that I added new functionality to the action (when I completely rewrote it), but the line between bug fixes, enhancements, and new features (which warrant a minor version bump) can sometimes be subtle or just outright opinion, so I'm sure someone could disagree with the action being at v1.1 instead of roughly v1.3 or so.

For what it's worth, I expected to bump it to v1.2 soon and will try to make it as painless as possible for people to pin their version bounds as tight as they wish.

It's worth nothing that the implementation of github actions itself treats everything after the @ as a "git committish" (or really anything that can be stuck after git checkout), so tags, branch names, hashes, short-hashes, etc., are all fair game should someone really want to pin their action version exactly.

[sol]

Somewhat related (@cartazio sorry for hijacking this issue), in the top-level README it reads:

A Collection of GitHub actions for interacting with Haskell.

So let's assume we add an other action, e.g. haskell/actions/run-tests, how would we version this? One obvious solution would be to just version them together, which would kind of work as long as both actions don't introduce breaking changes.

But what would we do when say e.g. run-test introduces a breaking change and hence requires a major version bump? The naive implication would be that setup would also continue on v2.* and that users of haskell/actions/setup@v1 would not get any updates anymore.

Or is the idea to have a separate set of tags for each action so that a user would e.g. specify

uses: haskell/actions/run-tests@run-test-v1

?

Or maybe ask @AlexeyRaga if he is open to the idea of widening the audience of the haskell-actions org, so that a user would specify:

uses: haskell-actions/setup@v1

or

uses: haskell-actions/run-tests@v1

?

[cartazio]

if only github had nested projects support, a la gitlab :)

[AlexeyRaga]

We have been thinking about it too, and came to the conclusion that having multiple actions in one repository isn't ideal because of the versioning: bumping a version for one action results in a version bump for all the actions within the repository, and this is very confusing.

So we ended up having one repo per action (here: https://github.com/haskell-actions/)

Perhaps this is also the reason for GH itself having a repo per action. Even heavily related actions (like upload and download artefacts) are modelled as different repositories by GH. So perhaps a repo per action isn's a bad idea after all.

[hazelweakly]

I went with one repo because it's been pretty rare in my experience that one needs to introduce backwards incompatibility into a github action. It's usually easy enough to preserve existing behavior and extend things with new options. I also didn't want to clutter the haskell org with more repos until I had been able to talk to more people about things. (I had only a few days to get this repo migrated over since the previous one was archived somewhat suddenly)

I also didn't know the haskell-actions org existed, at all, or I probably would've tried to get that opened up first.

As it is, it's possible to split out haskell/actions into separate repos and continue to reference them here so that haskell/actions/setup and haskell/setup-action both worked (or some other solution).

So let's assume we add an other action, e.g. haskell/actions/run-tests, how would we version this? One obvious solution would be to just version them together, which would kind of work as long as both actions don't introduce breaking changes.

But what would we do when say e.g. run-test introduces a breaking change and hence requires a major version bump? The naive implication would be that setup would also continue on v2.* and that users of haskell/actions/setup@v1 would not get any updates anymore.

Yeah that's correct. You can get around this by using branches to make it easier to ensure that v1 could continue to update and only relevant code would change, but it's not the most pleasant. This is the same strategy you need to use if you want to backport changes across versions in a single codebase anyway.

---

So, I guess the question is. Should this repo be changed to haskell/setup-action, migrated to haskell-actions/setup, or remain as is? And what should happen to the haskell-actions org?

[AlexeyRaga]

I think that the problem was not backwards compatibility per se. It is more like a cognitive load: because new versions are released regardless on whether the action has changed or not, the version name is now meaningless most of the time.
But I admit that it is kind of a personal feelings, just like some people like monorepos and lock-step versioning and other do not.
So please don't read my comment as "you are doing it wrong", I was just showing that we had exactly the same question and why we came with this answer :)

[sol]

One more option: How about using an independent (aka orphan) branch for each action. This allows for two things:

1. Version each action independently.
2. Do the namespacing through tags only (e.g. haskell/actions@run-tests-v1 vs haskell/actions/run-tests@run-test-v1), as each independent branch can have its own actions.yaml at the project root.

For comparison:

haskell/actions/run-tests@v1           # namespacing through directories + no independent versioning (status quo) (1)
haskell/actions/run-tests@run-tests-v1 # namespacing through directories + independent versioning of actions (2)
haskell-actions/run-tests@v1           # namespating by using separate repos at haskell-actions (3)
haskell/actions@run-tests-v1           # namespacing + versioning by tags (new suggestion) (4)

Downside of (1): Does not allow for independent versioning of actions.
Downside of (2): Not DRY (the action name, here run-tests, has to be spelled out twice).

[sol]

An other downside with the current setup is that actions in subdirectories can't be published to GitHub Marketplace. The same limitation applies for using orphan branches.

The relation between a published action on GitHub Marketplace and a repositories is strictly 1-to-1.

I'm not sure if publishing an action to GitHub Marketplace provides much value. Still, if it's my call, I would vote for using separate repositories (e.g. haskell/setup-action).

[cartazio]

I think Simon H makes a good point. Even though it means I’ll have to adjust my repos again

…

On Tue, Jan 19, 2021 at 10:24 AM Simon Hengel ***@***.***> wrote: An other downside with the current setup is that actions in subdirectories can't be published to GitHub Marketplace. The same limitation applies for using orphan branches. The relation between a published action on GitHub Marketplace and a repositories is strictly 1-to-1. I'm not sure if publishing an action to GitHub Marketplace provides much value. Still, if it's my call, I would vote for using separate repositories (e.g. haskell/setup-action). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQSLCXZ2ZWZL766NBI3S2WP4NANCNFSM4VEZ25YA> .

[amesgen]

I am not sure if it is intentional that the v1 tag does not point to the same commit as v1.2 (just noted due to GHC 9.0).

FWIW there are ways to automate this, e.g. actions-tagger (used by the official actions/upload-release-asset).

[hazelweakly]

Yeah that was unintentional. I've been procrastinating on setting this up, but it's time to sit down and write myself a pipeline that versions/tags/etc things when they get merged to main. I'll see if I can get that done this weekend

[amesgen]

Any updates on this? Eventually (not urgent by any means), I would be nice to either get v1 point to the latest v1.x tag, or to clarify that haskell/actions/setup does not follow this versioning scheme.

EDIT: v1 now points to the latest release.

[andreasabel]

Recent incarnation:

• Splitting this repo into one repo for each action! #141

[andreasabel]

Closing this issue in favour of #141.