Release/Tag new version

[djui]

In order to use Go Dep effectively with semver, please release or tag a new version. Using revisions with many open source project dependencies makes Go Dep much less convenient. The latest version is roughly 1 year and 22 commits in the past thus I could argue a new version is likely. It also seems lately new features were thus further strengthen the idea to bump the version.

[geototti21]

👍 on releasing new version

[geototti21]

👍 on releasing new version

[lithammer]

It doesn't work with the new vgo build tool either (it looks for 0.2.0 instead of 0.2).

$ vgo build
vgo: finding github.com/google/uuid v0.2.0
vgo: github.com/google/uuid v0.2.0: unexpected status (https://api.github.com/repos/google/uuid/git/refs/tags/v0.2.0): 404 Not Found
vgo: finding github.com/google/uuid v0.2.0
vgo: github.com/google/uuid v0.2.0: unexpected status (https://api.github.com/repos/google/uuid/git/refs/tags/v0.2.0): 404 Not Found
vgo: unexpected status (https://api.github.com/repos/google/uuid/git/refs/tags/v0.2.0): 404 Not Found

[lithammer]

It doesn't work with the new vgo build tool either (it looks for 0.2.0 instead of 0.2).

$ vgo build
vgo: finding github.com/google/uuid v0.2.0
vgo: github.com/google/uuid v0.2.0: unexpected status (https://api.github.com/repos/google/uuid/git/refs/tags/v0.2.0): 404 Not Found
vgo: finding github.com/google/uuid v0.2.0
vgo: github.com/google/uuid v0.2.0: unexpected status (https://api.github.com/repos/google/uuid/git/refs/tags/v0.2.0): 404 Not Found
vgo: unexpected status (https://api.github.com/repos/google/uuid/git/refs/tags/v0.2.0): 404 Not Found

[djui]

@renstrom That is a vgo problem. You need to specify the exact tag, not the semantic version name: thus: https://api.github.com/repos/google/uuid/git/refs/tags/0.2 works.

Of course this can be helped with by renaming or adding a tag v0.2.0, but I think as Dep can handle this, vgo should do so as well.

[djui]

@renstrom That is a vgo problem. You need to specify the exact tag, not the semantic version name: thus: https://api.github.com/repos/google/uuid/git/refs/tags/0.2 works.

Of course this can be helped with by renaming or adding a tag v0.2.0, but I think as Dep can handle this, vgo should do so as well.

[lithammer]

True. But I guess my point is; if a new release it cut, make it v0.3.0 instead of v0.3.

[lithammer]

True. But I guess my point is; if a new release it cut, make it v0.3.0 instead of v0.3.

[djui]

I understood your point, sorry if that was unclear. I guess my point is: I believe semver does not the require the leading v, it's a useful convention and Package Dependency Managers should support both spellings (and one might argue about the interpretation of trailing zeros; I believe it's pretty common to release and then see [v]1.0 as [v]1.0.0).

This could be short-coming of vgo not wanting to support Git, where one could list all tags and then check if the desired version exists under a different spelling. Just looking hard for zip-filenames makes this more difficult.

[djui]

I understood your point, sorry if that was unclear. I guess my point is: I believe semver does not the require the leading v, it's a useful convention and Package Dependency Managers should support both spellings (and one might argue about the interpretation of trailing zeros; I believe it's pretty common to release and then see [v]1.0 as [v]1.0.0).

This could be short-coming of vgo not wanting to support Git, where one could list all tags and then check if the desired version exists under a different spelling. Just looking hard for zip-filenames makes this more difficult.

[mattfarina]

@djui you are right that semver does not require the leading v per the spec. That's the reason glide didn't require it. The go community has been pushing to require it. I'd like to get deps handling to a place it doesn't. I'm not sure the direction vgo is headed. To be the most compatible in the go ecosystem it's worth adding the leading v.

[mattfarina]

@djui you are right that semver does not require the leading v per the spec. That's the reason glide didn't require it. The go community has been pushing to require it. I'd like to get deps handling to a place it doesn't. I'm not sure the direction vgo is headed. To be the most compatible in the go ecosystem it's worth adding the leading v.

[djui]

bump any ideas on how to move forward on this?

(v0.3.0 is fine with me)

[djui]

bump any ideas on how to move forward on this?

(v0.3.0 is fine with me)

[ashoksahoo]

This package is currently in development and the API may not be stable.
The API will become stable with v1.
Should be moving to v1 if its stable.

[ashoksahoo]

This package is currently in development and the API may not be stable.
The API will become stable with v1.
Should be moving to v1 if its stable.

[djui]

I think it’s fine to say it’s still in development, I assume that’s what v0 expresses. And thus a v0.3.0 would convey a similar instability.

I guess there is a difference between stability and update frequency.

[djui]

I think it’s fine to say it’s still in development, I assume that’s what v0 expresses. And thus a v0.3.0 would convey a similar instability.

I guess there is a difference between stability and update frequency.

[mattfarina]

If the API is unstable than doing releases such as v0.3.0 is extra important.

This library is imported by hundreds of others and that's just looking at the publicly known open source projects. Breaking the API without having releases will cause a pain for those consuming this library.

[mattfarina]

If the API is unstable than doing releases such as v0.3.0 is extra important.

This library is imported by hundreds of others and that's just looking at the publicly known open source projects. Breaking the API without having releases will cause a pain for those consuming this library.

[pborman]

I plan on working on this package in the next month, but currently do not have the cycles to devote to it.

…

On Wed, Apr 25, 2018 at 8:06 AM, Matt Farina ***@***.***> wrote: *If the API is unstable than doing releases such as v0.3.0 is extra important.* This library is imported by hundreds of others and that's just looking at the publicly known open source projects. Breaking the API without having releases will cause a pain for those consuming this library. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE4QHYUiEcQ2z24YzXGDTSq8JN-WfVwXks5tsJD9gaJpZM4RTZn_> .

[pborman]

I plan on working on this package in the next month, but currently do not have the cycles to devote to it.

…

On Wed, Apr 25, 2018 at 8:06 AM, Matt Farina ***@***.***> wrote: *If the API is unstable than doing releases such as v0.3.0 is extra important.* This library is imported by hundreds of others and that's just looking at the publicly known open source projects. Breaking the API without having releases will cause a pain for those consuming this library. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE4QHYUiEcQ2z24YzXGDTSq8JN-WfVwXks5tsJD9gaJpZM4RTZn_> .

[ermik]

@pborman I'll buy you coffees and stuff

[ermik]

@pborman I'll buy you coffees and stuff

[nbeyer]

I'd like to bump this issue/thread, as Go 1.11 came out with module support. I was able to use the "0.2.0" tag with 'dep', but that's not working with 'go.mod' and 'go mod' commands. It seems the tag naming convention of having the 'v' prefix is solidifying.

I don't have any strong thoughts or opinions on whether there should be a version 1.0, version 0.3 or other version, but it would be extremely helpful to have tags that use the 'v' prefix for 0.2 and a new tag for a more recent release (whether that 0.3 or 1.0) that also uses the 'v' prefix.

As an FYI, to use go 1.11 module, I have to have a require statement like this:

github.com/google/uuid v0.0.0-20180827204232-d460ce9f8df2

This is basically saying, there are no version, so we'll call it version 0 with a date stamp and put the commit hash at the end.

[nbeyer]

I'd like to bump this issue/thread, as Go 1.11 came out with module support. I was able to use the "0.2.0" tag with 'dep', but that's not working with 'go.mod' and 'go mod' commands. It seems the tag naming convention of having the 'v' prefix is solidifying.

I don't have any strong thoughts or opinions on whether there should be a version 1.0, version 0.3 or other version, but it would be extremely helpful to have tags that use the 'v' prefix for 0.2 and a new tag for a more recent release (whether that 0.3 or 1.0) that also uses the 'v' prefix.

As an FYI, to use go 1.11 module, I have to have a require statement like this:

github.com/google/uuid v0.0.0-20180827204232-d460ce9f8df2

This is basically saying, there are no version, so we'll call it version 0 with a date stamp and put the commit hash at the end.

[pborman]

Sorry for the delay on this. This was during my "dark" period. I have updated my email address and will once again see github issues (I hope).

There is now a v1.0.0 version tag!

[pborman]

Sorry for the delay on this. This was during my "dark" period. I have updated my email address and will once again see github issues (I hope).

There is now a v1.0.0 version tag!