How should we handle tags in repos split from our previous mono-repo

[CharliePoole]

I came across a problem after I merged the latest changes to NUnit.Engine.Api. I wanted to do a release and applied the tag 4.0.0-beta.5. It turns out that this is in conflict with tags already in the repo. I'm assuming I'll find the same problem with the two other repos I split out, NUnit.Extensibility and NUnit.Agent.Core.

My assumption had been that tags would not come over as a result of the split. Clearly wrong! I asked duck.ai about it. Here's the key response...

---

Consider a package, which was previously created as part of a mono-repo. If the code is split out into its own repo, what are the options for dealing with tags.
Duck.ai said

You have three practical choices, depending on whether the old tags actually represent releases of this package:

1. Keep package-relevant tags as-is. If tags such as v1.2.0 referred to this package’s releases, retain them. When you extract the package history with git-filter-repo, it rewrites commits and generally updates the tags it processes to point to the corresponding rewritten commits. Check the result: tags that pointed to commits with no package changes may not be useful in the new repo. git-filter-repo processes the refs present in your clone, so make sure you fetched the tags and branches you want to carry over. GitHub
2. Rename tags to make their origin clear. If the monorepo’s tags were shared across several packages, names like monorepo-v3.4.0 or legacy-v3.4.0 can avoid confusing them with the new repo’s release versions. Git tags are repository-wide, so you can choose the naming scheme that makes sense for the new repository.
3. Start a fresh tag history. Omit old tags and begin tagging releases in the standalone repo—for example, start at v1.0.0 if that matches your versioning policy. Keep the old repository available as the source of legacy tags and release context. Tags can be removed from the new clone before publishing it; one migration account describes deleting all tags as an optional cleanup step. hisaac.net

A good default is to preserve tags that unambiguously represent this package’s releases, rename ambiguous monorepo-wide tags, and avoid carrying over tags unrelated to the package. Do the split in a disposable clone, inspect the resulting tags with git tag --list and git show , then publish the new repository.

---

I'd like opinions from the team as to the best way to handle this.

The first choice, keeping the tags, means I'll just jump ahead and release beta.9 now. That's easy but will probably leave some broken tags currently pointing to the wrong place due to use of --force in the past.

The second is possible and probably the most work as it involves looking through all the tags and making individual decisions.

The third (which is what I thought would happen, is also relatively easy.

A compromise may be possible, eliminating all pre-V4 tags and dealing with the V4 tags one at a time.

In addition to the question about these messed-up repos, I'd like to know what you think we should do in the future.

[CharliePoole]

Duck.ai mentions

Tags that "actually represent releases"

In our context, this would mean all tags execept

• Those containing "-dev" or "-alpha"
• This containing "-beta." followed by a second dot, e.g. -beta.4.9

These are of course easy to remove and should probably be done for all the repos I work on. In the past, labels were created for these and transient myget releases, which are no longer accessible anywhere. Now, using minver, we only create a label for releases that will be published to nuget.

[OsirisTerje]

I would do this as simple and pragmatic as possible, meaning I would just jump up to the next version manually. Specially when you seem to work only with beta versions. I would not waste time trying to clean things up more than that.
I have sometimes skipped much further up, e.g. if the monorepo had 4.0.0-beta.5, I would skip all the way up to either 4.0.0-beta.10 or even 4.0.0-beta.100. This is just numbers, they don't need to be in sequence. And once 4.0.0 is released, all the beta numbers are just old history.

Also, for nuget, you can't manipulate the versions there, they are immutable, so going higher up is the only solution. So option 3 above is not working. Option 2 doesn't make sense since nuget is involved either, and why should you bother with older tags that way?

And, making a distinct jump makes it very clear that anything lower than e.g. beta.100, that belongs to the mono-repo, anything from 100 and above is the new repos.

All older tags in various forms, I would just ignore them.

[manfred-brands]

I came across a problem after I merged the latest changes to NUnit.Engine.Api. I wanted to do a release and applied the tag 4.0.0-beta.5. It turns out that this is in conflict with tags already in the repo.

That would mean that you had previously 'released' such a version when the split-off code it was in the mono-repo.
You cannot start at beta 1 after splitting, but need to go higher.

As @OsirisTerje said, skip a few versions and go for 4.0.0-beta.10

[CharliePoole]

OK, that's what I'll do. The last beta from the mono-repo was beta.8, which is the highest beta number of all the potentially affected repositories. The console and engine (including also nunit.common) will continue on that sequence... 9, 10, etc. My newly separated repos will start at beta.100 from this point onward. As mentioned, sold betas may already have been overlaid, but we'll soon be past the point of worrying about them

I'll also take the step of removing labels for development releases that no longer exist on myget since it's easy to do and they serve no purpose.

@rowo360 This will affect our plans for which versions of NUnit dependencies to use for TestCentric. I'll send a revised list but for the coming beta release, they will most likely all be 4.0.0-beta.100.