
Go modules have a v2+ problem - nitinreddy88
https://donatstudios.com/Go-v2-Modules
======
cap10morgan
I see a lot of comments in here about the v2+ rule’s reason for existing being
to allow importing multiple major versions of a module. That’s not it at all.
As the blog post (which was easily Googled by me and explains things quite
well IMO) states: “If an old package and a new package have the same import
path, the new package must be backwards compatible with the old package.”

They’re trying not to break compatibility until a downstream developer
explicitly opts in to that breakage. The simplest way to do that is to give
the module a new name. And the simplest way to do that is append the major
version to the name.

Here is the post: [https://blog.golang.org/v2-go-
modules](https://blog.golang.org/v2-go-modules)

For more background on this principle, I recommend Rich Hickey’s Clojure/conj
keynote “Spec-ulation” from 2016: [http://blog.ezyang.com/2016/12/thoughts-
about-spec-ulation-r...](http://blog.ezyang.com/2016/12/thoughts-about-spec-
ulation-rich-hickey/)

~~~
ubertaco
That's weird, how then do other languages manage to solve importing
packages/modules cleanly without requiring that the name of the package
_include_ the version number, while still allowing developers to specify
exactly _which_ version of the module they want to use?

Surely _someone_ else has solved this problem before, like Rust's Cargo, or
Java's Maven, or JS's NPM, or Python's PIP, Ruby's Gems, or...

Unlike in _every single one_ of those other languages, this Golang decision
means that you can't pin to a specific minor version, or a specific patch
version (in the sense of MAJOR.MINOR.PATCH).

It's very in-character for the Golang team though: they value simplicity-for-
themselves no matter what the complexity-for-you cost is.

~~~
Thaxll
It's short sighted to think that the Go package managment is "simple", there
was a lot of thoughts and considerations that was put into it and improvements
over other languages ( even recent one like Rust ).

Good read: [https://research.swtch.com/vgo-
principles](https://research.swtch.com/vgo-principles) which answers some of
your questions.

~~~
stouset
"A lot of thought and consideration" was put into the ten previous approaches
they've attempted to solve this problem.

I'm starting to think that the reason they've tried so hard to avoid solving
interesting problems in the language is that every time they've tried they've
made something worse than every other alternative that existed in the problem
space.

------
grenoire
Re: "They need at the very least a section of the documentation that lays it
out clearly and in layman's terms."

As a Go outsider who's trying to get his feet dipped in the lake, trying to
use modules has felt... uneasy? I tried to look up the official resources on
the matter and found the official blog posts to be lacking concrete and
concise examples on the usage; documentation feels like it's written for
people who work on the project and already digested the unit tests as
examples.

As for the case of v2, similarly messy and undocumented. I also appreciate
author's call for action on warning messages in tooling.

Wasn't the unified tooling supposed to be a selling point for Go? It just
doesn't _feel_ good to use.

~~~
throwawayinfo
Poor documentation seems to be a Google culture thing. I suspect that's why
godoc is literally just source code comments wrapped in HTML.

~~~
dan_can_code
I have found this to be almost universal when it comes to reading / writing
documentation, not just Google.

I have come to the understanding that to write good documentation, you should
write it as soon as you have learned it, or at least, try and explain in a
similar way in the way you learned (which is not easy at all). I feel the
issue stems from abstraction. Once you become somewhat an expert in a topic or
develop a deeper understanding of said topic, you automatically abstract away
the information that lead you to that understanding in the first place.

Otherwise you end up reading or writing documentation with a bunch of
assumptions for knowledge and understanding, which are not only not stated but
may not be available to the person trying to get to grips with the technology.
A bit of a digression from the post, but I don't feel this is just a Google
thing.

~~~
scns
There is a name for it: The experts blind spot

~~~
dmitriid
Erlang's creator Joe Armstrong once said it like this (quoting from memory)
"There's a moment when you go from not getting it to getting it, and you have
about 24 hours when you remember both before and after, and that's when you
have to write things down. After that you won't remember how it was not
getting it"

------
deklerk
Hiyo,

I'm one of the co-authors of [https://blog.golang.org/v2-go-
modules](https://blog.golang.org/v2-go-modules).

One of the takeaways from this article was, "there needs to be more
documentation", and I think I can speak to that:

First, thanks for the feedback. We also want there to be a loooot more
documentation, of all kinds.

To that end, several folks on the Go team and many community members have been
working on Go module documentation. We have published several blog posts,
rewritten "How to write Go code"
[https://golang.org/doc/code.html](https://golang.org/doc/code.html), have
been writing loads of reference material (follow in
[https://github.com/golang/go/issues/33637](https://github.com/golang/go/issues/33637)),
have several tutorials on the way, are thinking and talking about a
"cheatsheet", are building more tooling, and more.

If you have ideas for how to improve modules, module documentation, or just
want to chat about modules, please feel free to post ideas at
github.com/golang/go/issues or come chat at gophers.slack.com#modules.

~~~
grey-area
As an everyday user of Go perplexed by this making it into the mainline, I'd
like to second the request to make this feature optional. More documentation
would be nice, but I'd prefer the default to change.

The assumptions in that v2 go modules article around the meaning of major
semantic versions do not jibe with the way the majority of software in use
today uses version numbers - they are most often used to denote new features,
which may or may not have breaking changes large or small, and small breaking
changes are tolerated all the time, often in minor versions. This assertion in
particular seems wrong to me for most software in use today:

 _By definition, a new major version of a package is not backwards compatible
with the previous version._

~~~
deklerk
Semver is very clear on what a minor vs a major change means.

> the majority of software in use today uses version numbers - they are most
> often used to denote new features, which may or may not have breaking
> changes large or small, and small breaking changes are tolerated all the
> time, often in minor versions

We're getting into opinion here. Let's be clear: semver very strictly,
objectively disagrees with this approach. In general, this approach of "what's
a few breaking changes in a minor release amongst friends" leads to terrible
user experiences.

Go modules takes the cost of churn, which in some languages gets externalized
to all users, and places it on the module author instead. That is far more
scalable and results in much happier users, even though module authors
sometimes have to be more careful or do more work.

~~~
grey-area
Thanks for working on the docs and engaging here, I know it can sometimes be a
thankless task.

I don't think it's a matter of opinion that the vast majority of software in
common use does not use strict semantic versioning, most likely including the
web browser and operating system you are using to read this comment, popular
packages like kubernetes, and the Go project itself in the mooted 2.0 with no
breaking changes. It is highly desirable to avoid significant breakage, even
to the point of ignoring strict semver and avoiding it across major version
changes! So I'm not arguing for encouraging packages to break, but rather the
reverse, I prefer the status quo pre go mod where packages are assumed not to
break importers, though sometimes small breakage happens and/or is acceptable.

Most packages use a weaker version of semver than the one you describe, which
is still useful, so I'm not clear why the go tools have to impose the very
strong version which is not commonly used. The difficulties introduced seem to
outweigh any benefit to me.

~~~
timidger
Because the version of web browser and the kernel more or less doesn't matter
because they care way more about backwards compatibility than the "vast
majority of software".

The kernel doesn't break user space. Web browsers' api generally remains
backwards compatible (how long did it take to remove flash - and you can still
install it if you want!)

~~~
grey-area
Prior to this change, all go software operated on this assumption (do not
break users of the pkg), which doesn't comply with strict semver.

It worked fine.

------
simiones
> Some projects like GORM sidestep the issue entirely by tagging their 2.0
> releases as far flung 1.x releases. That something of a solution, but smells
> terrible.

Amusingly, the Google protobuf team did a similar thing for the Go protobuf
bindings. The new, backwards-incompatible `protobuf` module started with
version 1.20, while the old module is at 1.4.

If you've followed this, you know I've omitted one detail - they actually
changed the name of the module as well, from `github.com/golang/protobuf` to
`google.golang.org/protobuf`. Because, of course, Golang modules names are
actually URLs, not identifiers like in every other package manager out there.

~~~
xyzzy_plugh
> Because, of course, Golang modules names are actually URLs, not identifiers
> like in every other package manager out there.

They don't have to be URLs, though. What's the difference between
`google.golang.org/protobuf` and `org.golang.google.protobuf`?

~~~
a1369209993
> What's the difference between `google.golang.org/protobuf` and
> `org.golang.google.protobuf`?

There isn't one, because that's also a (mangled) URL, namely
"[http://protobuf.google.golang.org/"](http://protobuf.google.golang.org/"),
and should be rejected for the same reasons. A _identifier_ would be
"protobuf"; note the lack of any reference to the DNS domain.

~~~
grey-area
Do that and soon you're going to have to introduce namespaces, and you're back
to something that looks like urls.

People use these longer import identifiers because they avoid polluting the
global namespace, which be reserved for very important packages (in the case
of go the std lib).

~~~
munificent
_> Do that and soon you're going to have to introduce namespaces_

Everyone says this but there is strong evidence from npm and other package
ecosystems that you can go surprisingly far with a single flat global
namespace.

I think there is a paranoia among software developers about _potential_ name
collisions. But in reality, name collisions are rare and easily avoided. There
are 308,915,776 unique six-letter identifiers. Go to eight and you have
208,827,064,576 names to choose from.

~~~
grey-area
Namespaces are used for clarity (this is pkg log from org/user x), not because
we run out of letters.

~~~
munificent
The problem with that is that you're essentially using a hierarchy to attach
some piece of metadata to each package. The question then is what piece of
metadata is both so valuable to be worth enshrining in the name and yet so
unchanging that if its value changes, you're OK with every user of that
package having to migrate to the new identifier.

I have yet to see any particular bit of metadata that fits into that set.
Using "owner" like you do in your example here is a common choice, but also
very frequently changes. If you look around, you'll find lots of examples
where a package moved to a new owner and caused all sorts of problems because
now all the old name references no longer work.

You could try to pick some essentially descriptive property of the package
itselfs—maybe, say, "Net" if it has to with networking—like CPAN does, but
it's not clear that doing so adds any real value beyond satisfying our human
desire to put things in neat littly cubbyholes.

~~~
grey-area
I do have some sympathy with your views on this. Package identifiers don't
have to live in a hierarchy or include origin/owner. That they do in so many
systems indicates people find this information useful. I do disagree that
owner changes frequently - for the vast majority of packages that's not the
case.

Personally I find knowing the owner sometimes useful, and quite like the use
of urls in go imports as it also lets me look up the source. I've never found
it a huge problem (and I have moved packages from one place to another a few
times).

------
kardianos
In the go ecosystem, packages are imported per file. Go is designed for large
systems to evolve over time. You need to be able to refer to v1 and v2 at the
same time.

Thus the "/v2" requirement.

Yes, it is different. Stop complaining, do it, and it just works. Here is the
tutorial.

1\. Modify go.mod package path to include the "/v2" element. 2\. Commit. 3\.
Tag as "v2.0.0" 4\. Push tag.

I'm not seeing what is too confusing about releasing.

To consume, on packages that you want it, import the new package. Done.

Being able to import multiple versions without conflict has been extremely
helpful when I've needed new features in one version, but didn't want to
update (at the same time time) all the other places.

I really don't get why people don't like it, other then it is different then
what they expect elsewhere.

~~~
jacquesm
It's actually pretty much the only consistent and guaranteed backwards
compatible way to deal with such changes.

~~~
barrkel
There's no guarantee of backwards compatibility without limiting of forward
functionality. The trade-off can't be escaped.

If you can make do without any persistent state, or global or externally
visible resources (network connections, configuration files, etc.), then
you're OK. But that's a limitation.

~~~
roskilli
Modules that rely on global state for anything other than memory pooling or
what have you should be avoided. It’s a lot more testable and clean to return
a high level data structure that contains any of that state you would have
held before globally in the module and have that be the “context” or just the
parent data structure to any others that are spawned.

Global state makes thing impossible like parallel unit tests that all use
another module, or changing things like “MaxConcurrency” in a way that is
synchronized across goroutines that might already be calling into the third
party module.

My 2c.

~~~
barrkel
Of course. I'm not advocating global state. It's just that most real systems
have things like file systems, config files, databases, listening network
sockets, etc. These are inherently non-local.

------
grey-area
I'm still really not clear on why the Go team thought this was a good idea.

It makes no sense to me to try to impose this rule on the ecosystem - the
costs (confusion, multiple urls, multiple ways of doing it) vastly outweigh
the benefits (multiple versions in use at once), and if a particular project
wishes to use this rule, they could do so, without imposing it on the
thousands of packages which might want to use higher numbers to indicate large
feature releases or are already using higher numbers.

In theory a larger number in semantic versioning indicates breaking changes,
in practice small breaking changes are made all the time, it's a matter of
degree and the context of a given project, and people also use version numbers
for marketing or indicating lots of new features - a good case in point being
Go 2.0 which may well be backwards compatible to Go 1.0. That makes this
assumption in their blog false:

> By definition, a new major version of a package is not backwards compatible
> with the previous version.[0]

That's not the only, or even the main, reason projects use higher version
numbers.

I imagine lots of people will keep their version forever in the 1.x range to
work around this rule. I too believe Go should drop this requirement before it
is too late.

0\. [https://blog.golang.org/v2-go-modules](https://blog.golang.org/v2-go-
modules)

~~~
drvd
There is a difference between a software (executable) and a library. Semver is
overrated but at least common and well understood with clear semantics. And
no, Go 2 probably will be Go v1.23.

------
fourseventy
I knew about this rule and I still got bitten by it last week when I was
trying to upgrade a package. It's one of the many things I hate about go
modules.

As I understand it the reason for this design decision was to allow a project
to use multiple versions of the same dependency at once. To me this seems like
a pretty rare edge case. They burdened the 99% of users with weird V2 syntax
so that 1% of users could handle this edge case (which could have been handled
by other means).

~~~
xyzzy_plugh
It's not really an edge case, it's sort of to the core of how modules work,
and allows a whole slew of issues to be elided. See
[https://research.swtch.com/vgo-import](https://research.swtch.com/vgo-import)
for more background and examples.

> They burdened the 99% of users with weird V2 syntax so that 1% of users
> could handle this edge case (which could have been handled by other means).

Really the only burden lands on package authors who are making breaking
changes. And really, the path provided is so much easier than actually making
breaking changes for your users. Everyone wins.

~~~
grey-area
> Really the only burden lands on package authors who are making breaking
> changes. And really, the path provided is so much easier than actually
> making breaking changes for your users. Everyone wins.

The burden falls on every module developer who wants to use a version number
above 1.x. That is _not_ congruent with developers who make breaking changes
as you seem to assume.

There's an assumption here about v2 meaning breaking changes that not even Go
2 itself may adhere to (as it may well be more of a 'new features' version
number than a 'breaking changes' version number increment).

~~~
geodel
> The burden falls on every module developer who wants to use a version number
> above 1.x.

And this is fine as it gives module developers an opportunity to make breaking
changes which they wanted for quite some time. It makes much clearer for
module user as opposed to Java where one does not know which module will blow
up code was it 2.11 or may be 2.13.2 etc.

> There's an assumption here about v2 meaning breaking changes that not even
> Go 2 itself may adhere to

If anything Go is trying to be even more conservative that they are avoiding
breaking changes in 2.0 as opposed to being rash making breaking changes in
1.x. I see no problem with that.

~~~
grey-area
It directly contradicts the assertion that major versions must mean breaking
changes, the justification for forcing import urls to change.

------
fnoof
A consequence of the complexity is that some devs stay below v2 forever
because it’s easier. Backwards incompatible changes pile up in v0.x’s. It’s
then really difficult for consumers to install two versions of the same
package, which can happen with diamond dependencies.

~~~
mfcl
Do you have an example of such package? I've used Go modules for years and
never encountered that.

~~~
durbatuluk
someone cited kubernetes above

------
cybrexalpha
Go has a bigger tooling problem. Build systems are hard, and Go has decided it
doesn't want to be hard so it's ignored anything other than the "happy path".
I wish other Go dependency tools still existed.

------
marcus_holmes
I'm a huge fan of Go, and not a fan of dependencies at all, so I tend to
vendor everything.

Go mod just looks like a total mess from the outside. To be honest I (like
most gophers I've talked to) never really understood why dep wasn't adopted as
the official solution for this.

I'm resisting converting my projects to modules until there's a clear and
definite advantage to it. So far, none.

~~~
CamouflagedKiwi
I tried dep for a project of mine and could never even get it to the point of
doing anything useful. Conversely go mod took about three minutes to migrate
to and was super straightforward.

I am very happy that they did not adopt dep, it was in no way ready (and I
don't think it was going to significantly improve given more time).

~~~
marcus_holmes
True, there were problems with it, it wasn't perfect by any means.

I guess the main complaint at the time was that it appeared to be "not
invented here" syndrome. The community was converging on dep, and then the Go
team decided to do something different, for reasons that weren't completely
clear. It kinda rammed home the reality that Go is not a community project,
it's a Google product controlled by a small team. That definitely has benefits
and good points, but it doesn't match everyone's expectations.

------
kortex
What I don't understand is why they chose to put the major version as part of
the path part of the uri (/), as opposed to some other separator, e.g.
fragment (#). Especially since it's optional. You can always convert
"example.com/foo#v2" into the "/v2" if needed, but if you see "foo/v8" is that
a repo "foo" version major v8, a subfolder of "foo" named "v8" or a repo "v8"
in the project "foo"?

~~~
CHY872
It’s traditional at least with web browsers to not send the fragment to the
server. Query param would work, but implies your routes don’t change much
between major versions.

~~~
kortex
> It’s traditional at least with web browsers to not send the fragment to the
> server.

Ah, TIL, thanks!

I meant more "why must the import syntax use specifically this scheme to
denote versions". I guess backwards compat?

~~~
yencabulator
Import paths are used to figure out where to fetch the source code from. To
simplify a bit, if you see `example.com/foo/bar`, it works because there's an
appropriate meta tag at [https://example.com/foo/bar?go-
get=1](https://example.com/foo/bar?go-get=1) . The import paths are pretty
directly used as URLs.

------
enos_feedler
"I have seen many very large projects including Google owned projects get it
wrong."

As an ex-Googler I can tell you that this above statement can be more broadly
applied across _many_ developer facing Google products (most notably for me,
Android frameworks and libraries). Google's apps don't use the guidance and
recommendations we gave to external Android devs.

I wonder if there is something cultural about Google not even being able to
coordinate changes and improvements within the org itself.

------
compsciphd
I don't understand whats so hard at making it easy, if one just use source
repo tags (which in go module land you should be using).

1) your go.mod should include the version 2) the module itself always assumes
its the version of it's go.mod file 3) to release a version you just tag it
based on the version in the go.mod file (with later semantic versions being
considered the best and what go will use by default) so module authors have to
do.

so module authors dont have to do anything special besides include the version
in the go.mod file (and keep it up to date) + tag release appropriately in a
way that keeps to go's compatibility promise.

4) when you import a module, you specify what version you want (with a default
assumption of v1) so your go.mod would either include the module or
modules/v2... 5) your imports in actual .go files would not have to include
the /v2 as they would know based on the go.mod file.

you as the end user of the module will follow v0/v1 tag for as long as it
exists, but will have to modify your go.mod to use v2 if you want to switch.

does my conception not make sense?

~~~
mcdee
The point of having separate imports for separate versions is to allow for use
of (for example) both v1 and v2 of a module within the same codebase, if
required. Your idea would force a single version, which means that would no
longer be possible.

~~~
compsciphd
ok, reasonable, though it would seem that one could do both. i.e. for those
that dont want to include multiple versions, be easy, for those that need
them, then you have extra complexity.

------
sempron64
2-3 years ago I was working on a large project in Go with many dependencies.
We moved in the span of 12 months from go get, to glide, to dep, and when vgo
was announced I realized I was on a pointless treadmill, despite community
assurances that the current package manager is "blessed" and will be
maintained. I then decided that Go is actually quite unstable and is not yet
ready for enterprise projects, and recommend against it despite the fact that
I really like and agree with the design philosophy of the language.

~~~
kardianos
It would have been best to have skipped glide and dep. Sorry.

The Go the language is stable, and Go modules is stable and is the future.
Everything, including new features, is based on Go modules. That isn't
changing.

------
donatj
Author of the post here. Really neat to see something I posted _last night_ on
HN the very next morning.

With a night to sleep on it, I think requiring `/v0` and `/v1` would have been
the better option, that way you'd hit the issue _right away_ rather than years
into your project. Teach things early. I've updated the post with a note of
this idea.

I think that's likely not something they could add at this point however.

I don't even mean to be critical of the v2-ing itself, I just think it's
entirely non-obvious.

------
kstenerud
This is why I never use anything but "1" as the first number in my go modules.
The second number is the major (breaking changes) version field, and the third
number is the minor field (non breaking changes).

These are just the kinds of things you put up with when writing go code and
need to work around bad designs of the language and ecosystem.

------
earthboundkid
I think people are too quick to declare v1. All of my modules are
(deliberately!) v0 because v1 means "I commit to never breaking this API."
Most Go modules should be v0.year.minor, eg v0.20.5 for the fifth release this
year. You should only be using v1 if you have a lot of users, a set of core
maintainers, etc. etc.

~~~
perlgeek
How does that make anything better for the user?

They know they cannot rely on a stable API, which means they have to carefully
read the diff for every single upgrade, so saving no work over explicitly
picking a major version.

~~~
earthboundkid
The advantage is truth in advertising.

------
konart
Never realised this was a problem. How so?

Tag your version v2.0.1, import it as .../v2 in project - done. You don't even
have to read docs or blog posts to understand it, just look at the source code
of a new project, notice the ../vN part, see the corresponding tag in repo and
do the math.

------
blablabla123
I don't see any big problem. There is a blog post on the Golang website
explaining everything. (My only complaint is there is no cheatsheet on
golang.org for this) Also it's actually quite nice that it's possible to keep
all maintained - and possibly incompatible - versions on the same branch
without the overhead of a 3rdparty acting as package curator/distributor.

------
dilap
I wonder if they should've just required v1 or v0 when using Go modules†, so
that v2 and above didn't seem like a red-headed step child / surprising / non-
obvious by comparison.

The basic idea of having separate import paths for non-compatible versions of
a project seems, in fact, really good; an elegant solution to a tricky
problem. It certainly seems much nicer than secretly using multiple versions
of a package behind your back (especially when you consider that if this
happens and a package uses mutable internal state, you could actually get
broken behavior).

I guess for me the takeaway is in aggregate, people will be maximally lazy.
You need to make the correct thing be the easiest thing.

(†Also release a patch to older versions of Go to just ignore v1/v0, and error
for above, so you can have source compatible w/ both module and non-module
Go.)

------
saturn_vk
The whole premise that the "communication of this rule has been weak" is
rather weak. It has been hammered in throughout the development process of
modules, and is part of the official documentation.

If the author has missed the numerous blog posts throughout the development,
and hasn't read the official documentation, well, I'm not sure we can fault
someone else for that.

Luckily, it appears that the community has picked up the memo somewhere, as
there are quite a few v2+ modules around.

------
wallyqs
It has gotten much better but in our project we got bitten by this. I gave a
talk about it at GoSF last year if looking for some Go v2 modules
schadenfreude :)
[https://www.youtube.com/watch?v=8xAaZDSDWOc](https://www.youtube.com/watch?v=8xAaZDSDWOc)

------
shp0ngle
> Even as a seasoned developer, I found this write-up somewhat impenetrable

As is the usual case with these write-ups

------
ausjke
This is where "technical writer" profession shines, I know companies who have
technical writing teams do excellent job there, but if we leave it for busy
coders, that's what we got in the end.

------
apta
It's absurd that golang didn't take established solutions such as Java's
packaging system, and had to re-invent the wheel in a completely suboptimal
way.

------
alexandrerond
Modules had been in discussion for like years. Modules HowTo has been around
from day one and it tells about this very clearly. Modules adoption rolled
over a couple of releases which gave all the pointers they could..

Any minimally maintained project uses modules already. It is a must for any Go
programmer to be skilled at managing modules because otherwise things just
break. And yet it seems some people have lived under rocks.

People don't have time to RTFM, but apparently lots of time to complain and
write about things they should have known with minimal due diligence around
the tech they use. _shrug_

------
patatsuh
The dep fans try to strike back again?? I hoped we are done with this...

------
draw_down
> I brought the issue up at my local Go meetup, and no one had ever heard
> about the rule. They were very skeptical of me.

This resonates with my experience writing Golang (plus Bazel) this year.
Anything that isn’t working, you must have just messed up and did something
wrong. It can’t be that something is actually broken here.

Even in this comment thread, “stop complaining and just do it.”

~~~
throw_m239339
This kind of dismissive behaviour have been in the Go community since the
beginning, unfortunately. It's the product of Rob Pike's behaviour and his
rejection of "complexity". But you can't just dismissing complexity by deeming
it irrelevant, it's there.

Ian Lance Taylor is probably the only person in the Go team that has a more
pragmatic approach to things. The rest is a bunch of deaf people led by the
blinds and a few vocal gatekeepers outside Google that will publicly humiliate
you if you stray away from the current orthodoxy.

------
alexruf
The Go Team has actually communicated this matter extensively through your
blog ([https://blog.golang.org/v2-go-modules](https://blog.golang.org/v2-go-
modules)).

~~~
brabel
This is mentioned in the article.

The problem is that the official solution, as mentioned in the article, seems
really bad... you just have to copy the whole project into the `v2` folder,
then do the same for a future `v3` and so on... it kind of goes against normal
practices of using version control tools for this kind of thing, where each
version would be in a different branch, not folder.

Not to mention having duplicate files like this can make finding files in your
editor a bit confusing as well.

Though I like how Go solved dependency management and dared to go on a
different path than almost every other package manager, this particular
solution seems to go a bit too far?!

~~~
vlowther
Or you could just have separate branches for major versions. That works too,
and everyone seems to forget it.

~~~
jpttsn
I do only this. Copying the codebase into a subdirectory seems like a kluge.
It baffles me that they recommend that solution; seems like too much backward
compatibility.

------
rezeroed
What a mess. Starting with the GOPATH. This is far worse than the lack of
generics which has had much airtime. For all the historical credits Pike and
Thompson have, I don't know what they're doing here, it's making them look
like buffoons; maybe they're not involved with this. I've mostly abandoned Go
because of this ongoing red flag mess. Is there an end goal? The "we're
watching the community" sounds like a weak excuse.

~~~
_wldu
Ken has been retired for years.

