use git tags that the go tools recognize

[melato]

Consider using git version tags of the form: vn.n.n, as per the go modules reference: https://go.dev/ref/mod#versions

For example, use "v0.2.0", instead of "incus-0.2".

The reason is that commands like "go get" and "go mod" put in the go.mod file tags like "v0.2.0", but not "incus-0.2".

I am not asking for full semantic versioning compliance (which has to do with when each of the three numbers is incremented). I just want to be able to use a specific version and see it in the go.mod file.

Example:

In an empty directory do:

go mod init test
go get github.com/lxc/incus@incus-0.2
cat go.mod

You will see this line, which does not have a tag:

require github.com/lxc/incus v0.0.0-20231027190220-0a5f3e4fd588 // indirect

go get creates a pseudo-version, because it did not find a vn.n.n tag.

Now try with a repository that has the "v" tags:

go mod init test
go get gopkg.in/yaml.v2@v2.4.0
cat go.mod

The last line is:

require gopkg.in/yaml.v2 v2.4.0 // indirect

This makes it easier to check that I am using the version that I intended to use.

I had the same issue with LXD version tags.

[stgraber]

I've changed the existing tags to match the semver format.

[adamcstephens]

I appreciate the new tag format, as this is what most projects seem to be using these days. Unfortunately, by renaming the existing tags this has impact on us downstream packagers.

It's mostly moot as I'm updating the nixpkgs version to the new 0.3 tag, but removing the previous tag format means that anybody going back to try and build 0.2 or 0.1 from our package definitions will not be able to. I don't suspect anybody to go and do so, but it's something you may want to keep in mind in the future. It's helpful to treat tags as mostly immutable references, even if technically they are not.

[stgraber]

Yeah, I did consider that but had the opposite problem with our own tooling which was then getting confused and always selecting the incus- tags rather than v tags due to alphabetical/version sorting...

In the end I went with the approach that since we're only 3 releases in, it shouldn't cause too much breakage to just get rid of the old tags. Github also conveniently lets you move a release definition to a new tag which helped avoid breakage there at least.

[rgl]

@stgraber please go a step deeper with the versioning, and apply the three component version everywhere, from my viewpoint, these also need to be changed (to make it easier for other tooling to match all the versioning):

1. the release artifacts (from incus-0.3.tar.xz to incus-0.3.0.tar.xz)
2. the release title (from Incus 0.3 to Incus 0.3.0)
3. the debian package version (from 0.3-<date> to 0.3.0-<date>)

[stgraber]

Not really planning to. There is a good reason for the tags to have the otherwise pointless trailing .0, but pushing that onto the release versioning for non-LTS is just going to mislead users into thinking that we issue bugfix releases on those versions when we don't.

[rgl]

As a user, generally speaking, versioning is something which is somewhat arbitrary, project specific, and tends to change over time. As such, I assume almost nothing about it. I much prefer to have a consistent/uniform versioning among all artifacts, as that make things simple to cross-reference.