Proposal: to release as a Go Module, archive repo and fork to github.com/gofrs/uuid.go@v0.4.2

[theckman]

I floated this idea very roughly in the #gofrs Slack channel, and it's to effectively rename this repository to avoid the Semantic Import Versioning (SIV) component of Go Modules

Context

When this repository was forked from github.com/sator/go.uuid, we chose to keep the same versioning scheme as the original project to help the migration be easier for folks. We did not need to consider Go Modules at the time, and so it was easy to start the project at a major version higher than the original project and assume it was low cost to do a major version increase as necessary.

Unfortunately, Go Modules has changed the situation, and so with hindsight it would have been better to not follow the versioning of the original project and to instead release as a v0.x version.

Proposal

We would create a new repository, github.com/gofrs/uuid.go, and push the master branch of this repository to that one. We would not push any of the tags from this repo there. We'd then create a new tag, v0.4.2, at the same commit† as v4.2.0 of this repo. We would then update the README of this repo to point there, and archive the project. Any new development would happen there on v0.

† same commit + addition of go.mod file / any updates for the rename

[cameracker]

I view this suggestion as a net negative.

First, we would be asking our users to change their import paths to make this change, which is precisely what we are trying to avoid with adopting modules in the first place.

Second, with a v0, we'd be communicating to users incorrectly that this is an unstable package when in reality this package is highly unlikely to experience any significant breaking changes to the interface in the near future. The only time we've had to make a breaking change was to remove the v2 features because they were inherently unstable. There is nothing on the horizon suggesting we'd do anything similar anytime soon.

Third, we'd lose context and history in this repo by switching over to a new name. We'd lose searchability and name recognition we've built over the last several years.

To me its preferable to make no changes and keep on going, or to bite the bullet and include modules in this current repository. There are a relatively small amount of people who are complaining about lack of module support. This seems not broken, I'm not inclined to fix it.

[dylan-bourque]

It's been a while so I don't remember all of the specifics, but there were issues with consumers that were still referencing the undecorated github.com/gofrs/uuid import path pulling in unexpected versions (older commits, iirc) when this repo originally opted into modules at v4.x. Or maybe is was that modules-based consumers were getting an older comment than non-modules consumers.

The end result of that, for lack of a better term, cluster@#$% was that repos like this one that already have v2+ semver tags should do a major version bump when opting into modules. That would mean we'd have to cut github.com/gofrs/uuid/v5 and all of our consumers would be forced to change their import paths everywhere anyway.

While I don't particularly like moving/renaming the repo, I kind of feel like it's not any worse.

[cameracker]

I don't necessary disagree with your opinion, but last I checked, we would no longer to kick up the major version of the package to introduce modules. It could be done at V4 and we'd be ok.

[dylan-bourque]

Opting into modules will mean moving to github.com/gofrs/uuid/v4 though. Is that really all that different?

[theckman]

I thought we'd need to move to v5, since adopting modules at a higher version was considered a "breaking change" by the system. @cameracker do you have context you can share on that?

@dylan-bourque your last comment is the point I think I failed to make. Fundamentally, the amount of work we'll push onto consumers is the same, and we can avoid them having to do that again in the future.