Go modules: why no_version != latest ?

97 views
Skip to first unread message

Rolf Veen

unread,
Mar 3, 2021, 2:35:49 AMMar 3
to golang-nuts
Hi, all. 

In my not painless transition from GOPATH to modules, I would like to understand why import paths without a version are not equal to 'latest', which is what happens in many other contexts: no version specified, use latest. There is kind of a discontinuity now, where the namespace without version is for 'latest v0' or 'latest v1', and the namespace with version for v2 and up. Also, IIUC, we are forced to use a version in the import path if a package has reached v2, forever until the end of time.

If this point has been raised earlier, as is probable, please kindly point me to the relevant discussion.

Rolf.

Volker Dobler

unread,
Mar 3, 2021, 5:09:25 AMMar 3
to golang-nuts
On Wednesday, 3 March 2021 at 08:35:49 UTC+1 rolf...@gmail.com wrote:
In my not painless transition from GOPATH to modules, I would like to understand why import paths without a version are not equal to 'latest', which is what happens in many other contexts: no version specified, use latest.

It's pretty simple. It is a combination of what semver means and how
package identity works:
 - The import path determines _identity_ of a package.
 - A new major version in Semver means: Incompatible change.

Incompatible change basically means "a different package" for Go, it is
no longer the "same" package (with just additions or fixes), it is a different
one now and thus needs a different import path.

If "no version suffix" would mean "latest" this could not hold any longer
as latest might be v1.0.0 or v3.0.0 and these cannot be the same package
as they are by definition of Semver different and thus need different import
paths.
"no version suffix" meaning "latest" version would undermine one of
the fundamental building blocks of how Go works: Packages and that
packages are identified by their import path _alone_.

It is the same with "versioning" APIs or REST services. People tend
to think that "version 3" of an API/Service is the same API/Service
than version 2, just a newer version. It is not if Semver is taken serious.
Version 2 and 3 might be very similar but they are _incompatible_ and
this a different API/Service. You cannot "version an API". The API
is either compatible or not and if not it's not the "same API".

V.  



Reply all
Reply to author
Forward
0 new messages