Monorepo: git tag format

[evertonfraga]

We need a plan for the git tags for when we migrate the repos to the monorepo. I see the current standard is to create vM.m.p, producing v1.3.3, for example.

Worth mentioning the tags should be renamed prior to migration, otherwise 50% of them would present conflicts.

The ideal tag syntax
Some monorepos use the package name and version to name the tag, in a npm-like syntax. In our case, considering the scoped packages, we could have tags named as:

• @ethereumjs/vm@1.2.3
• @ethereumjs/account@2.1.1

Some other repos concatenate version and name with a dash (not my preferred):

• @ethereumjs/vm-1.2.3
• @ethereumjs/account-1.2.3

Question:
Is there any system that depends on the current github tag format?

---

Some of our repos have tags on different formats
There are 6 tags across the main candidates to the monorepo that are not prefixed by v. (1.0.0 vs. v1.0.1).
In the process of renaming tags to the new format, I can migrate them to whatever format we agree upon.

[holgerd77]

@evertonfraga Great that you've caught that! I would be ok with the first tag name version, so e.g. @ethereumjs/vm@1.2.3. There is no internal system depending on the tag format. A slight exception is the testing repository, which uses tags as being the only form of releases, there are no npm releases there due to npm package size restrictions (on a side thought along with this: I think we shouldn't include the testing repo to the monorepo, since this makes everything very heavy. The tests submodule is more than half a GB in size, and it takes ages to e.g. clone the repo).

Would be great if the non-fitting tags are unified as well.

[evertonfraga]

Ok, reporting my progress on this subject.

This is the portion of the migration code that handles tag renaming — strictly speaking, re-tagging with new names.

For context: there are two types of Git tags:

• Lightweight is the format Github uses by default and is just a hash map to a commit (e.g: v1.0.3 => 89b1d3d...).
• Annotated carries more metadata, has its own commit hash and is stored as a separate object in .git. This one is used for signed commits

The migration handles both cases, keeping the GPG signatures from whoever made them first place.

When you head to a repository tags page, the dates shown alongside tags are from the commits the tags points to, so migration-wise the original tag dates will be kept. 👍

[evertonfraga]

A downside: GitHub Releases are not git objects and are stored by GitHub platform. As of today, they can't be transferred from one repo to another in a clean way, not even across forks.

So I have two items to deal with:

1. ethereumjs-vm own releases: given that releases have a 1 => 1 relationship to git tags, for this repo I need to first create the new tags, point the current releases to the new tags, then delete the old tags.

2. Recreate releases from other repos towards the main one. GH does not let me fake the creation date, so I will need to make the date explicit in the notes "Originally released in 2019-05-03". The monorepo will start with a 144 releases, which requires me to add them in a chronologic ordering, to keep things tidy.

[holgerd77]

Thanks for the fine-grained work on this. 🙂👍

[holgerd77]

Closed by ethereumjs/ethereumjs-monorepo#561