Tagging/versioning of this repo

[umarcor]

I suggest to use a tag like v0 (while still testing) and then later v1.
What do you think?

Originally posted by @Paebbels in edaa-org/pyEDAA.ProjectModel#31 (comment)

[umarcor]

I suggest to use a tag like v0 (while still testing) and then later v1. What do you think?

Agree. However, GitHub Actions does not support semver yet. Unlike JS's package.json or Python's requirements.txt, GitHub Actions cannot interpret that v0 is the major identifier of v0.x.x. Hence, maintainers need to explicitly force-push the major (v0) and minor (v0.x) tags, each time a patch release is tagged. For instance:

• Tag 0.0.1, v0.0 and v0, all pointing to the same commit.
• Tag 0.0.2 pointing to a new commit, and force push v0.0 and v0.
• Tag 0.1.0 pointing to a new commit, create v0.1 and force-push v0.
• ...

Since that is cumbersome, most developers do not provide the minor tag, but just the full and the major formats. See:

• docs.github.com: actions/creating-actions/about-custom-actions#using-tags-for-release-management
• The recommendation to "move" tags actions/toolkit#214 (comment): "Full semver will come with the using GPR to release actions". That was 2 years ago. We are still waiting...

On the other hand, my concern is that pyTooling/Actions includes multiple reusable pieces which might be bumped independently. For now, we have at least the JS Action with-post-step and the collection of Reusable Workflows. In fact, we might handle each reusable workflow independently, but let's consider them to be a single code unit for now. Do we want to have separated tags as follows?

• reuse-0.0.0
• reuse-0.0.1
• ...
• wps-0.0.0
• wps-0.0.1
• ...

and reuse-v0, wps-v0, etc. See an example hosting multiple actions in a repo: https://github.com/actions/toolkit/tags.

Or do we want to handle the versioning of the whole pyTooling/Actions repo together?

[Paebbels]

How is it possible that v0 and v0.1 are identical in GHA?

Have they explicitly implemented a bug to break the behavior of a reference in Git?

Anyhow, I would like to start with a single version for all items in this repo.
I also would forward either tags or branches (a version branch is a sliding pointer like a tag) as long as it shouldn't break the API (e.g. new required input parameters).

[umarcor]

How is it possible that v0 and v0.1 are identical in GHA?

Have they explicitly implemented a bug to break the behavior of a reference in Git?

I don't understand. Git allows generating multiple tags pointing to the same reference, isn't it?

Anyhow, I would like to start with a single version for all items in this repo.

Ok. Shall we start with tag 0.0.0 (or v0.0.0?) and tag v0?

I also would forward either tags or branches (a version branch is a sliding pointer like a tag) as long as it shouldn't break the API (e.g. new required input parameters).

Yes. Whenever we want to forward v0, we need to create a new 0.x.x tag, and then move v0.

[Paebbels]

Yes, Git has references in the directory .git/refs, There are subdirectories called heads (tips of a branch = head) and tags. Technically, they are identical. From usage they are stored in different folders and used by convention as mutable (branch) and immutable (tag). In addition, Git has special references like .git/refs/HEAD being the currently active pointer (normally) to a branch.

That why you can use git checkout <branch> or git checkout <tag> or git checkout <hash> the same way, because they are identical. That's why I said, you need to explicitly implement a bug to break the core of Git.

And yes, many branches and tags can point to the same hash (commit). The reference is technically just a human readable alias to a 160-bit SHA1 hash.

I prefer to use vX.Y.Z for tags to keep it consistent with other repositories. We could use branches with rXX as release or revXX to denote the workaround we need for GitHub.

[umarcor]

That why you can use git checkout <branch> or git checkout <tag> or git checkout <hash> the same way, because they are identical.

Then, we can use either tags or branches. We might start with using tags, which is used by most Actions. When GitHub changes the recommended approach, we can switch to having v0 be a branch. That will be transparent for users.

That's why I said, you need to explicitly implement a bug to break the core of Git.

I don't understand what is broken in the core of Git. Branches are mutable by convention and tags should not. However, that is not a technical problem, but a usage/practice issue.

I prefer to use vX.Y.Z for tags to keep it consistent with other repositories. We could use branches with rXX as release or revXX to denote the workaround we need for GitHub.

I tagged v0.0.0 and v0. So, the discussion/enhancement would be whether to make v0 a branch (no breaking change) or create an r0 branch (breaking change). If we are going to use v* tags (not mutable) and r* branches (mutable), maybe we should start doing that now. I.e., I will remove the v0 tag that I just pushed.

[umarcor]

As discussed in a meeting, we will use branch r0. I created it and removed the v0 tag already.