vgo and handling major versions

[Kaveh Shahbazian]

(IMHO - assuming vgo would care about this)

About branches:

Having branches for major versions helps greatly. A major version can literally be a whole different package by breaking the API or even introducing a completely new one.

However keeping some previous major versions might be desirable and different branches help with hotfixes. The pattern of having master, develop, release-*, hotfix-*, support-*, etc is pretty common (outside of Go world).

At the same time being forced to maintain the major version inside import paths (as in `import "gopkg.in/some-package.v3"`) is not desirable too.

It would be nice if vgo could handle something like (in .mod files) `pkg >1.2.1 branch-name-*` and the `*` part could be a major number and the `1.2.1` is tag. The `branch-name-*` part is a pattern for branch name.

The only part remaining, is how the editors should show the source (with goto definition) which can be solved by have physical different directories for different branches.

[wilk]

On 26-02-2018, Kaveh Shahbazian wrote:

> It would be nice if vgo could handle something like (in .mod files)
> `pkg
>>1.2.1 branch-name-*` and the `*` part could be a major number and the
> `1.2.1` is tag. The `branch-name-*` part is a pattern for branch name.

If I understand what you mean, I would resolv this with replace
directive of go.mod to a clone of the branch. This clone could be
a subrepositories of the dvcs to can keep everything.

--
William

[Kaveh Shahbazian]

I feel uneasy a bit about tags (since they can come from anywhere/any-branch). But maybe that's just being over pessimistic, about handling/managing major versions.

And IDEs should use .mod files to reach for the source code of a definition - which is very helpful at development time. Now there are situations that I'm worried about that might damage the development experience - like when a package, five levels down is using an older major version of a certain package and our package is using the latest version of that certain package.

[Maxim Ivanov]

gopkg.in already  "redirects" different import paths to different branches in your repo. You then use correct module name in go.mod in each branch and it all just works.

As for "major version inside import branches" , it seems to be a cornerstone of whole vgo proposal, so I doubt it is up for discussion at all :)

[Kaveh Shahbazian]

+1

I love gopkg.in and use it extensively - gopkg.in + tags + GOPATH is my happy combination.