Release/Tag new version about uuid HOT 14 CLOSED

👍 on releasing new version

from uuid.

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

from uuid.

@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.

from uuid.

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

from uuid.

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.

from uuid.

@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.

from uuid.

bump any ideas on how to move forward on this?

(v0.3.0 is fine with me)

from uuid.

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.

from uuid.

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.

from uuid.

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.

from uuid.

from uuid.

@pborman I'll buy you coffees and stuff

from uuid.

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.

from uuid.

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!

from uuid.