Tags in git allow just about the same naming options as branches, and "v" prefix is just a convention not a requirement. So rather than applying a tag v1.3.2 you could use a "folder structure" such as library1/v1.3.2 and library2/v3.1.2. Today I learned that you can use `git describe --match="library1/v*"` to get the version relative to just "library1" if you are versioning this way (in a monorepo, for instance).

It seems like what you describe is what golang supports: the folder structure in the tag name must match the folder structure in the repository. That's pretty cool.

Well, if they're actually independent, clearly those shouldn't be in the same repository...

"Independently usable" does not have to mean "totally independent". The libraries could be related to the same product using the same infrastructure.

That doesn't follow. Why should they not be in the same repository? They may be related but independently usable.

mono repo approach (or something to that direction)

Do people use a mono repo approach with different parts of the repo having different version numbers? The way I thought of it, the whole point of mono repo is not that.

Sometimes, yes. Monorepos use monolithic versioning internally, but they may use semantic versioning when publishing libraries.