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?