Breaking API Change

[packrat386]

0ef6afb breaks the API that's been stable for years. Why is this important enough to change with no warning, despite the community standard to be avoiding breaking API changes without some kind of versioning system? The original issue indicates some sort of deprecation warning was considered, but seems to never have been implemented. If users are going to have to rug pulled out from under them with no warning, why should we use this library?

[markbates]

I just hit the same problem with github.com/markbates/pop and github.com/gobuffalo/buffalo this breaks both projects.

I agree with @packrat386 this is a big breaking API change that was sprung on everyone.

Can we please revert that change, for now, and create a path to making the breaking change?

[jjuarez]

I have faced the same issue

[packrat386]

We've already fixed it in our code, so honestly undoing it is only going to cause more problems for us, but either way this approach to API stability is a major problem. This should have been NewV1WithError() or something.

EDIT: I understand that reverting might be the best solution, just pointing out that in some cases the damage is already done.

[sbowman]

At this point if you want to change the API, you should create a new project or version it somehow. Your change basically broke a dozen projects at our company.

[davidpope]

Agreed with @sbowman , this broke a bunch of our projects.

If you use version tagging, at least those of us using glide and 'go dep' can protect ourselves by pinning our major versions. For example, if you tag f58768 as 1.2.0 and 0ef6af as 2.0.0, the fix is simple on our end.

I agree that the proper immediate fix is to revert, however.

Edit: For clarity, we have already protected ourselves by pinning to the latest August version (0ca0c2). I'm suggesting tagging here simply as a good pattern to follow.

[prowley]

Also broke the goa project.

[glerchundi]

I agree with you all that these kind of breaking changes should be treated in a much more soft way. BUT, consider two things:

• It's a personal project and he can do whatever he wants,
• If you're pinning to master branch, you're already doing it wrong.

[jinroh]

This is also an issue for us because we rely on the dep chain hermes -> sprig -> go.uuid.

Could we introduce another method instead of making a breaking change, like uuid.NewV4Safe() or something along those lines ?

[ivucica]

Original request to make the change that broke people, #18, talked about "let's warn people for 6-12mo" which I don't think happened.

[packrat386]

#18, talked about "let's warn people for 6-12mo" which I don't think happened.

I think that's the important bit here. If there was something like a deprecation warning or a new method, I don't think anyone would be opposed to the change. I, for one, certainly prefer a library that returns an error rather than panicking. The issue isn't with the content of the change, but with how it was rolled out.

[thurt]

regarding how to handle the error, is this error merely transient? ie. can we simply keep retrying to create UUID until we do not get an error?

[jasonkeene]

Software changes.

(•_•)
( •_•)>⌐■-■
(⌐■_■)

Deal with it.

[ivucica]

It can sometimes change more slowly, in an ecosystem that encourages building all from head? Which was the original, laudable plan, too :-)

…

-- Sent from Gmail Mobile on iPad

[ktnyt]

I personally want to support @thurt's suggestion about looping until the method succeeds for uuid.V*. As @jinroh and others pointed out functions that return multiple values should have been implemented separately. I think this project has grown popular to the point where destructive changes in the interface can no longer be excused for the project being personal. Sure it's no Python 3 but still a lot of people, myself included, love and rely on this amazing piece of work.

[evillemez]

A version tag pre/post this breaking change would be helpful. In the meantime, I'll try and pin to a specific commit before the change.

[cstockton]

There are many options besides committing a breaking change and causing months of collateral damage. If you want a good example of what happens when a project has a breaking change look at sirupsen/logrus#451 - as projects slowly update their code you end up with some dependencies fixed, some broken for many months. It's most painful for the people who import the broken packages (like me, importing osrg/gobgp), because I have no control over when it is fixed.

The best course of action is to revert and create a proper version and import path for those who ARE in the position to update and wish to do so. This will also allow both versions to live side by side. Please don't leave all these projects dealing with random interruptions as various projects update over the next N months :/

EDIT: To be clear the faster it is reverted the least damage done to the ecosystem. The people who already fixed their changes are clearly agile enough to revert and it's fresh on their mind so they will know exactly where to look. The people who have not yet had to research this will never have to. Leave the change and EVERYONE who uses this library will eventually be affected.

[evillemez]

For those using dep, I changed my Gopkg.toml to this, which pins to the last commit on Jan. 2, the day before the change:

[[constraint]]
  name = 	"github.com/satori/go.uuid"
  revision = "063359185d32c6b045fa171ad7033ea545864fa1"

Not the best solution, but unbreaks things for now.

EDIT: Use [[override]] instead of [[constraint]] if it's a transitive dependency: https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md#override

[ktnyt]

Please let me apologize in advance for jumping the gun here but I was starting to get the impression that reverting the interface was pretty urgent. I tried not to destroy the modified interface as much as possible while reverting the global namespace NewV* functions (which I believe is the heart of most issues) to the original function signatures. If the NewV* methods for the Generator interface needs to be reverted there is a whole lot more to do (which might be better off just completely reverting the past few commits).

[qct]

though breaking changes bring tons of damage to developers, but I want to say why don't you use release version, like v1.1.0?

[ivucica]

Because go get is still a reasonable tool to use in the ecosystem.

[grugnog]

Also seeing fails on github.com/Masterminds/sprig and github.com/qntfy/kazaam

[mattwilliamson]

It could have easily been done by adding a new function instead of breaking tons and tons of projects. I, myself have about 20 that were with 8 developers on my team -- 160 changes not including laptops. Switching to github.com/google/uuid was faster and easier than implementing error checking.

By the way, why should generating a uuid ever fail? It's just a stinking random byte array. Fail to get MAC address? Fail to get timestamp? At this point I would rather have the application panic and dump a trace, because something is catastrophically wrong.

[kevinburke]

In rare cases, you can't read random bytes from crypto/rand.Reader.

[mattwilliamson]

Retry or return nil? Backwards compatibility is important stuff. I don't know why you would downplay it.

[kevinburke]

I'm not downplaying it. See earlier in the thread where I described how I maintain a fork now. You asked why it could return an error and I told you.

[domino14]

@satori pls

[ktnyt]

It's been three months so I feel like this issue is pretty much, technically, closed in terms of discussion (unless we hear back from @satori ). No reversion. Deal with it, or resort to an alternative.

tl;dr

What happened?

Some old interfaces (uuid.NewV1, uuid.NewV2, and uuid.NewV4) were broken: wrap them with uuid.Must to achieve identical results (e.g. uuid.Must(uuid.NewV4())).

Alternatives?

If you want to use a pre-change compliant API go with kevinburke/go.uuid. google/uuid is another seemingly good alternative but beware as it publicly states that it may be unstable (although I doubt there being any huge API change).

[domino14]

That’s fine. We just want him to tag it so that we can use dep without overrides.

[theckman]

Some members of the Go community are now maintaining a fork of this repo. We've just cut a v2.0.0 which is for the breaking change. Our fork keeps v1.2.0 available, if you still need it:

• https://github.com/gofrs/uuid