search

google / uuid

Go package for UUIDs based on RFC 4122 and DCE 1.1: Authentication and Security Services.
BSD 3-Clause "New" or "Revised" License
5.26k stars 362 forks source link

Release/Tag new version #29

Closed djui closed 6 years ago

djui commented 6 years ago

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 commented 6 years ago

đź‘Ť on releasing new version

lithammer commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

djui commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

bump any ideas on how to move forward on this?

(v0.3.0 is fine with me)

ashoksahoo commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 https://github.com/google/uuid/issues/29#issuecomment-384321235, or mute the thread https://github.com/notifications/unsubscribe-auth/AE4QHYUiEcQ2z24YzXGDTSq8JN-WfVwXks5tsJD9gaJpZM4RTZn_ .

ermik commented 6 years ago

@pborman I'll buy you coffees and stuff

nbeyer commented 6 years ago

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 commented 6 years ago

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!