Go modules: why no_version != latest ?

[Rolf Veen]

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]

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.