Use semver for releases

[myitcv]

I note #3936.

But in light of modules requiring versions to be proper semver versions (v0.53 is not a valid semver version, v0.53.0 is), would it be possible to have hugo releases follow semver?

Thanks

[bep]

As this would require some work, you need to add some arguments to "why"?

Note that:

• Hugo isn't a traditional library
• I don't know how Go modules behave with < 1.0.0 versions
• When we increment to 1 I will make sure to take it to v1.0.0, but you need to give weighty arguments if you want us to spend time on this before then.

[myitcv]

@bep - apologies, I should have added more context in the original report.

In module-mode, go get github.com/gohugoio/hugo will only work with valid semver versions. Hence:

cd $(mktemp -d)
go mod init mod
go get github.com/gohugoio/hugo
go list -m github.com/gohugoio/hugo

gives:

github.com/gohugoio/hugo v0.49.2

That is to say, it is not possible to add a module requirement for a release of github.com/gohugoio/hugo other than for valid semver versions (0.49.2 is the latest valid semver version).

In Go 1.12 this will also affect go get outside of a module context now that golang/go#24250 has landed:

GO111MODULE=on go get github.com/gohugoio/hugo
$GOPATH/bin/hugo version

gives:

Hugo Static Site Generator v0.49.2 linux/amd64 BuildDate: unknown

Given that Hugo has already moved to using modules for its dependencies, this is the preferred way of installing via the go tool.

So where people are looking to:

• add Hugo as a requirement for their module
• install Hugo "globally" on their system using module-mode

they will have to resort to doing:

go get github.com/gohugoio/hugo@master

or a specific commit, which seems less than idea.

In response to your points/questions:

• Hugo isn't a traditional library

Yes I realise, but as I've pointed out above this affects a "global" go get as well as situations where people want to add Hugo as a (tool) requirement to their modules. Add tool dependencies is a well-defined concept with modules.

• I don't know how Go modules behave with < 1.0.0 versions

There is nothing special here. The only thing conveyed by being < 1.0.0 is that there are no guarantees about compatibility, per https://semver.org/#semantic-versioning-specification-semver:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

• When we increment to 1 I will make sure to take it to v1.0.0, but you need to give weighty arguments if you want us to spend time on this before then.

I'll let you decide based on the examples above whether you consider this worthwhile or not.

Just to point out that it would probably be sufficient to add additional tags as part of the release process. For example, in addition to tagging v0.53, you could also tag v0.53.0. Yes the version reported by hugo version would/might still read v0.53, but at least the go tool in module mode would be able to resolve to a valid semver version.

[bep]

OK, I understand.

I would suggest that you start out by creating an issue upstream (https://github.com/golang/go/issues) and apply a fix there -- which should be plenty more effective than forcing Go's definition of semver millions of dependencies on the internet.

• To me v0.53 is both correct semver and much preferred before v0.53.0
• And even if you argue that v0.53 is somehow wrong, I cannot see any ambiguity or any other problems in adding some leniency into the "go modules parser" and say that v1 == v1.0 == v1.0.0. I think a "raise of hands" on Twitter or similar will show that people agree that this is the most sensible solution.

Just to point out that it would probably be sufficient to add additional tags as part of the release process. For example, in addition to tagging v0.53, you could also tag v0.53.0.

That would break Hugo's automated release process.

[myitcv]

This has previously been discussed in golang/go#27528. The go command is documented to work with tags that are valid semver versions, according to the definition at https://semver.org/, i.e. the definition that other package managers use, so not its own definition. According to that definition, v0.53 is not a valid semver, whereas v0.53.0 is.

As @bcmills points out in that linked issue, the Go tool does resolve, for example, go get $pkg@v1.0 to the latest valid semver version with a v1.0 prefix.

I think a "raise of hands" on Twitter or similar will show that people agree that this is the most sensible solution.

I think this amounts to changing the go command to work with tags that are invalid semver versions. I don't believe this is the right approach; we have a definition of what constitutes a valid semver version, for the sake of all tools that work with versions it seems to make sense to work to that definition. But if you disagree, then perhaps you'd be better placed to raise the issue in the Go project.

That would break Hugo's automated release process.

Can you explain how this would break things? It would require an additional step, yes, i.e. the addition of v0.53.0; what would break?

[myitcv]

That would break Hugo's automated release process.

Can you explain how this would break things?

Or alternatively, please can you point me towards the scripts/etc that make up the release procedure? I'd be happy to help look at what's required to update the release procedure.

[bep]

Or alternatively, please can you point me towards the scripts/etc that make up the release procedure? I'd be happy to help look at what's required to update the release procedure.

A new release is triggered by a valid semver tag. We cannot have duplicate tags, as that would, for one, trigger 2 release builds ... I'm doing the Hugo releases. And while there are tests and ways to verify those scripts, you really don't know if it works until you do a release. And I really hate having to debug, clean up and fix a broken release ...

I still think Go Modules are broken in one way or the other, and will open an issue on Go's issue tracker about it, if you don't.

Either:

• v0.53 should be accepted as v0.53.0
• v0.53 should trigger a validation error. There will, even for projects that try to do good vs semver, be "tagging typos" etc., and just ignoring this problem and picking a random old version does not sound right.

Until then I will happily accept updates to the Hugo README/build instructions with workarounds to this issue:

• There are release binaries
• git clone + go install

[myitcv]

A new release is triggered by a valid semver tag.

Is it possible therefore to switch to v0.54.0 for the next release (i.e. just v0.54.0 by itself, without v0.54)?

v0.53 should trigger a validation error.

This is likely covered under golang/go#26420 or golang/go#28590, so please feel free to add any points to either of those.

[bep]

Is it possible therefore to switch to v0.54.0 for the next release

No, this will have to wait. The combined risk is too big. That and I still think this is a case that needs to be handled upstream. So this will have to wait.

[myitcv]

No, this will have to wait.

Ok, thanks for confirming.

I still think Go Modules are broken in one way or the other, and will open an issue on Go's issue tracker about it, if you don't.

Just to confirm, I won't be raising this issue so will leave it up to you whether you want to raise one. Because as I said above I consider the current position of the go tool to be "more correct" with respect to the semver definition https://semver.org/ and therefore any other tool that needs to handle valid semver versions.

[myitcv]

The combined risk is too big

Just thinking about the risk aspect of this a bit more. Isn't the risk of this somewhat (entirely?) mitigated by the fact you've already demonstrated valid semver versions as working, e.g. v0.49.2? Or is there something special you need to do in that case?

[moorereason]

I agree with @myitcv. The Go team has said they will only support valid semver. The semver spec is clear that X.Y does not meet the spec. At some point, we need to make the move to semver.

[bep]

Or is there something special you need to do in that case?

When I say that there's risk/work involved in something, does it really matter exactly what it is?

I have done some test in this area, and I don't see how that should not work fine with Hugo's version of semver in Go 1.12. In my tests, I always get the correct and latest version.

▶ GO111MODULE=on go1.12beta2 get -u -v github.com/bep/mod-c && mod-c
go: finding github.com/bep/mod-c latest
c v0.54

The Go team has said they will only support valid semver

They should strongly consider being a little more lenient in that definition. v1.5 and similar is a very common semver variant. Picking an arbitrary v0.0.4 version before the latest v1.5 version does not sound in line with Russ Cox' great article on this subject. I have experienced this myself as a module consumer. And even if you probably should try to contact the module owner to get him/her to change his/her version scheme, you mostly end up with the pragmatic choice of pinning to a specific commit -- and lose any automatic patch updates.

If the Heartbleed fix had been released in OpenSSL v3.1 I think we can all agree that it would be really, really bad if your package manager handed you v3.0.8 when you asked for the latest.

At some point, we need to make the move to semver.

Perhaps. But that point is not now.

[myitcv]

When I say that there's risk/work involved in something, does it really matter exactly what it is?

In matters only in as much as I was offering to help investigate/fix.

I have done some test in this area, and I don't see how that should not work fine with Hugo's version of semver in Go 1.12. In my tests, I always get the correct and latest version.

https://github.com/bep/mod-c does not have any tags, hence you are getting master by default, so this is not a valid test:

$ export GOPATH=$(mktemp -d)
$ export PATH=$GOPATH/bin:$PATH
$ cd $(mktemp -d)
$ go mod init example.com/hello
go: creating new go.mod: module example.com/hello
$ go version
go version go1.12beta2 linux/amd64
$ go get -u -v github.com/bep/mod-c
go: finding github.com/bep/mod-c latest
go: downloading github.com/bep/mod-c v0.0.0-20190131090956-67c8d233c9d9
go: extracting github.com/bep/mod-c v0.0.0-20190131090956-67c8d233c9d9
github.com/bep/mod-c
$ go list -m github.com/bep/mod-c
github.com/bep/mod-c v0.0.0-20190131090956-67c8d233c9d9
$ mod-c
c v0.54

[bep]

Yea, ok -- I thought I had pushed the tags. Now I get:

 GO111MODULE=on go1.12beta2 get -u -v github.com/bep/mod-c && mod-c
c v0.53.1

But that is only with GO111MODULE=on. I think this will be the common use case:

▶ go1.12beta2 get -u -v github.com/bep/mod-c && mod-c
github.com/bep/mod-c (download)
c v0.54

[myitcv]

I think this will be the common use case:

I don't have any evidence to conclude whether or not more people have switched to using modules/GO111MODULE=on in either Go 1.11 or 1.12(beta), I was simply reporting the issue for the case of when the user is in module mode.

[myitcv]

Thanks @bep, looks good to me:

cd $(mktemp -d)
go mod init mod
go get github.com/gohugoio/hugo
go list -m github.com/gohugoio/hugo

gives

github.com/gohugoio/hugo v0.54.0

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.