Towards v2.0.0

[acln0]

This bug tracks development towards a v1.3.0 release and a more formal announcement of the library.

• as far as I can tell, we have kept backwards API compatibility, so we don't need a major version bump
• we added new API in Export DefaultGenerator (formerly generator). #9, which warrants a minor version bump
• Fuzz testing #2 and Replace testing framework (go-check) with standard library assertions #15 would be resolved by rework tests from gocheck to stdlib testing #17 when it is reviewed
• more input in Minimum supported Go version #18 would also be nice to have

Those things aside, do we want to do anything else for v1.3.0?

[theckman]

I have been thinking about just going with a v2.0.0 for a bit, and then reading through the #gofrs Slack channel this morning I think we've come to a bit of a decision that we need to do a major version release.

So summarize the discussion for any who aren't part of the Slack group: the original project had made API changes that should have resulted in a major API bump, but didn't.

I think we should align on the milestone release now being about 2.0.0.

In terms of additional features, I think we should do a quick triage of issues and PRs over in the old repository and look for any candidates. If there's something that would be a breaking API change that we want, maybe we should pay the tad now. I don't have any off the top of my head.

RFC:

• Thoughts on going with v2.0.0?
• Does anyone have any features or fixes from the old repository that they feel should be made here?

[niaow]

If we think we are going to go with v2, we should clean up the generator interface.

[theckman]

@jadr2ddude are you able to elaborate on which changes you'd like added?

[niaow]

@acln0 suggested that the Generator interface was not necessary

[acln0]

I don't think we should do v2.0.0 right now.

Yes, the original project broke API at some point in the past, and perhaps a semver purist would say that we need to bump the major version retroactively. I don't think we need to, at least not right this moment.

When upstream broke API, users were unhappy, but they probably fixed their code, or moved to another package. For the users that stayed, I think the first thing we need to offer is a drop-in replacement for satori/go.uuid with critical flaws fixed, and backwards compatible enhancements (such as the DefaultGenerator we exported).

I think expectations and ease of adoption matter more, at least as long as the project is still young.

A potential v2.0.0 would slow us down quite a bit, and I'm not sure it would help users very much.

For a potential v2.0.0, I think a redesign of the API is in order. Generator probably needs to become concrete and not an interface (such an interface belongs in caller's code, I believe), we need some way to deal with the Getuid thing, however obscure it may be, etc.

[theckman]

@acln0 Let's disregard what the old project did and look at our own git history (and subsequent tags). The commit that was made to add the error returns was 0ef6afb. Unfortunately, that's one commit after f58768c which is the 1.2.0 release.

Because our history is tied to the original project, if github.com/satori/go.uuid had released a 1.2.0 or 1.3.0 with the breaking change I'd agree, but that didn't happen. I feel we are obligated to do the 2.0.0.

I think we could rebrand 1.3.0 as 2.0.0, and we should not be afraid to release a 3.0.0 shortly there-after if it makes sense.

Edit: To clarify, we could say that 2.0.0 is our initial release that includes the changes made by Satori after 1.2.0, and fixes some bugs within those changes. And that some of those changes are breaking, because of the introduction of the error returns. And it gives consumers a major version to point their fixed code to, and not the master branch.

[acln0]

Aha, I see now. I was not aware of the fact that the breaking change in upstream was not tagged in any way.

This makes v2.0.0 more compelling for us. Nevertheless, I think our v2.0.0 should be backwards compatible with satori/go.uuid@0ef6afb, to ease adoption. A potential v3.0.0 could make the API enhancements I proposed in my last message, in the future.

[theckman]

I think we should have enough things done within the next day or so to get this out the door.

[acln0]

Agreed. @theckman Tag it when you think it's ready. Once that happens, @jadr2ddude can resume #20.

Nice work, everyone! 👍

[theckman]

Once #30 is merged we'll tag the v2.0.0. Expecting to do this in ~8-10 hours.

[theckman]

https://github.com/gofrs/uuid/releases/tag/v2.0.0