Add major-minor-release workflow

[s-weigand]

Here is the promised workflow, for major and minor tag releases, which works with PEP440 versions.

Creates major+minor tags on

• 'normal' tags (e.g. v2.0.0)
• post tags (e.g. v2.0.0.post0)

Does not creates major+minor tags on

• dev tags (e.g. v2.0.0.dev0)
• pre tags (e.g. v2.0.0.rc0)

Also, it saves the original tag name as an annotation in the major and minor tags.

I tested some example tags on my fork.

[webknjaz]

@s-weigand it has recently been brought to my attention that rewriting tags is a terrible idea. They are supposed to be immutable. It's branches that actually need to be used as a floating pointer. It seems like the best way of implementing this is to actually use branches with names like v1 / v2 and just make sure that the corresponding tags actually belong there. WDYT?

[s-weigand]

@webknjaz While it is true that the idea behind tags is that they are immutable, github themselves rewrites them for major releases of their own actions (e.g. https://github.com/actions/cache/releases). I can only speak for myself but I really seldom look at tags of a repo, but quite often at the branch tree (especially with GUI tools) and having many branches would clutter that. So my opinion on this is so to say 'When in Rome, do as the Romans do.' and I would stick with the pattern github uses for its own actions.

Also, the tag of the exact release stays immutable, so the way I see minor or major tags, in general, isn't as strict tag but more like a convenience thing equivalent to something pip install jupyter~=2.1. If you want the assurance that you get the exact version you want, for one reason or the other, you can always specify the fully qualified version.

[webknjaz]

Well, I'd not idealize what GH does — they often make questionable decisions. I think it's better to have branches called v1/v1.1/v1.2, and so on. But for the patch releases, there would be actual tags. When the minor version is bumped, the previous branch could be turned into a tag and removed so the number of branches wouldn't be too high. I'm not sure if the development should be kept in the main branch or if the major like v1 should become a repo default, though.

And yes, I agree that patch versions should be used mostly — dependabot even knows how to bump those. But what I'm saying is that all the tags must stay immutable over time, no exceptions. Just because somebody else breaks the rules doesn't mean that it's a good idea to subvert Git's ideology. They still haven't solved the security issue that arises from using moving targets on the platform level meaning that all the users have to either use trusted Actions or use commit SHAs and audit every change on their own since there's no fair guarantee that some random action author won't go rogue and retargets a tag or a branch to some malicious commit (it's even more dangerous when done silently and temporarily — it leaves almost no trace in logs).

[s-weigand]

Ok point taken. Also, I wasn't idealizing the decision of GH to overwrite tags. It was more like that the meaning of minor/major tags are different in a GH-action context, especially since I have only seen them in that context at all. In all cases I know, a package manager would take care of resolving loosely specified versions. It would be nice if the workflow was that smart so using minor/major versions would be all up to the users and not the developers.

Anyway, WDYT about having the branches all in a folder e.g. release/v1 / release/v1.1? I think creating a tag from a minor release branch would leave us with the tag overwriting again, in case of a post-release. As for changing the default branch to v1, IMHO this would complicate things if the was to be a v2 release and for users, it would basically be the same as currently pointing to master.

[webknjaz]

Anyway, WDYT about having the branches all in a folder e.g. release/v1 / release/v1.1? I think creating a tag from a minor release branch would leave us with the tag overwriting again, in case of a post-release.

Yeah, that's a good idea. Except I'd maybe call those rolling-release or something else explicitly pointing out that the "version" is actually a floating pointer to some moving target.

As for changing the default branch to v1, IMHO this would complicate things if the was to be a v2 release and for users, it would basically be the same as currently pointing to master.

Fair enough.

[webknjaz]

@s-weigand so I was thinking it may be a good idea to have branches like unstable/v2 potentially having more commits than release/v2 that should point to the latest v2.*.* tag (or release/v2.* for that matter). Any contributions would go through unstable/v2 and on release, it would be tagged with v2.*.*, and then release/v2 and release/v2.* would be fast-forwarded to that tag.