Re: [go-nuts] Go += Package Versioning

[Nic Pottier]

Right, any self import needs to change for the vgo case. (but not for
the go case unless you force everybody currently using your library to
start using semantic versioning paths)

-Nic

On Fri, Feb 23, 2018 at 10:06 AM, Zellyn Hunter <zel...@gmail.com> wrote:
> On Fri, Feb 23, 2018 at 10:01 AM Nic Pottier <nicpott...@gmail.com> wrote:
>>
>> Right, that works for clients of the library (and I did manage to get
>> my projects working with that and it now feels magical) but authors of
>> modules above v1 are posed with a bit of a quandary as to how to give
>> their users a nice vgo version without breaking current users on plain
>> go.
>
>
>  Why not just commit a mod.go with v3 in it at the root, and tag it
> 3.{y+1}?, assuming you're already on v3.y? Adding mod.go doesn't break
> existing users. vgo users will use different import paths. If you like, you
> can branch off of your 1.x tag, add a mod.go with v1 in it there, and tag it
> 1.{x+1}. Same for v2.
>
> Oh wait, is it a problem because your self-import paths need to change (or
> not) depending on whether the client is using vgo? I think I'm unclear on
> that detail :-)
>
> Zellyn

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go += Package Versioning

[Nic Pottier]

On Fri, Feb 23, 2018 at 7:59 AM, roger peppe  wrote:
> As Russ pointed out to me, you can work around that by using a
> 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
> section. If you've got that, it ignores the version tags.

Right, that works for clients of the library (and I did manage to get
my projects working with that and it now feels magical) but authors of
modules above v1 are posed with a bit of a quandary as to how to give
their users a nice vgo version without breaking current users on plain
go.

>From Russ's latest post I think the answer is you put a v3 subdir in
your repo with a copy of the code, add a mod.go and update both the
root and v3 until vgo becomes adopted everywhere.

-Nic

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go += Package Versioning

[Nic Pottier]

Thanks for the great write up Dave, you've inspired me to "try harder" to 
use it on a few of my projects after running into similar issues.

As you noted, my remaining big question mark is how existing libraries that 
are above v1 transition to a vgo style while remaining backwards compatible 
during the transition. That seems like the biggest wrench to adoption. (if 
we can convince everyone to start using v# in import paths) I was preparing 
to open some PRs with dependencies of mine to introduce go.mod files, but 
as I understand it that won't be enough for those above v1.

On Friday, February 23, 2018 at 2:22:32 AM UTC-5, David Anderson wrote:
>
> I'm curious how we could upstream the changes I had to make to client-go. 
> I had to rename module-internal imports, which will break existing non-vgo 
> uses of the library, but vgo offers no alternative to this renaming that 
> I'm aware of. It looks to me like there's no graceful upgrade path for this 
> module. The repo structure works either for pre-vgo clients, or for vgo, 
> but not both at once.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Build started to fail with 1.10

[Nic Pottier]

This is almost certainly because your .travis file is specifying your 
version as `1.10` vs `"1.10"`

So your build is building with go 1.1 instead of 1.10.

Ran into this myself this morning.

-Nic

On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов wrote:
>
> Hey guys, 
>
> One of my build started failing with 1.10. Basically I'm building a 
> wrapper around a C library and it fails with: 
>
> # runtime/cgo
> gcc_libinit.c: In function '_cgo_try_pthread_create':
> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>   struct timespec ts;
>   ^~
> gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
> [-Werror=implicit-function-declaration]
>nanosleep(, nil);
>^
> gcc_libinit.c:97:18: error: unused variable 'ts' [-Werror=unused-variable]
>   struct timespec ts;
>   ^~
> cc1: all warnings being treated as errors
> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>
> Any hint's what's causing this? 
>
> Cheers, 
> Vladi
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.