@Jason
That's really helpful, thanks. I/we adopted Go long after modules were
introduced and have never had to deal with GOPATH mode, which probably
explains why I didn't read the aspects relating to that (or wiped them from
my memory subsequently - lol).
On Friday 19 April 2024 at 02:02:36 U
@Jolyon
> Is this the correct approach to major-v-bumping a module?
There are two approaches supported by the Go tooling. This is one of them.
Neither is more correct than the other, there are pros and cons to each.
Using a major version directory has the benefit of working transparently
with G
As a matter of fact, I gained a somewhat complete understanding of the
whole concept of Go modules and the go-get facade mechanism through writing
a simple pkgsvr (https://xrfang.coding.net/public/go/pkgsvr/git/files).
However, before this issue came up, I hadn't noticed the significance of
the ta
Is this the correct approach to major-v-bumping a module? I had understood
the "vN" slug in the module to be a "virtual" element, signalling the
deliberate introduction of an upgrade to a new major version of a
dependency. i.e. it avoids (or at least makes less likely) the chance of
inadverte
Yeah. After clean modcache.
Thanks!
Jason Phillips 于2024年4月17日周三 22:41写道：
> It works for me, now.
>
> > go get go.xrfang.cn/hap/v2@v2.0.0-alpha.2
> go: downloading go.xrfang.cn/hap/v2 v2.0.0-alpha.2
> go: go.xrfang.cn/hap/v2@v2.0.0-alpha.2 requires go >= 1.22.1;
> switching to go1
It works for me, now.
> go get go.xrfang.cn/hap/v2@v2.0.0-alpha.2
go: downloading go.xrfang.cn/hap/v2 v2.0.0-alpha.2
go: go.xrfang.cn/hap/v2@v2.0.0-alpha.2 requires go >= 1.22.1; switching
to go1.22.2
go: upgraded go 1.22.0 => 1.22.1
go: added toolchain go1.22.2
go: added g
Hi Jason,
Acutally I wrote the go hosting service myself. According to your comments,
I modified the output now it is:
$ curl https://go.xrfang.cn/hap/v2?go-get=1
https://e.coding.net/xrfang/go/hap.git";>
But it still not working:
$ GOPROXY=direct go get -v -x -u go.xrfang.cn/hap/v2@v2.0.0-alph
