Release v1

[djmitche]

I see you've switched to go modules by adding go.mod. Could you now release a semver-formatted version of this library? I think that's as easy as git tag v1.0.0 and pushing.

[luna-duclos]

I just took over maintainership of this project, so I'm not quite comfortable doing this just yet, but if things go well I might check with Dave Chenney eventually to do this.

I'll leave this hanging for a while.

[djmitche]

Sounds good. The downside of not doing semantic versioning is that every commit to main is a "release", so the pressure's a bit higher to make sure you're right every time you click "Merge PR" than it would be with semantic versioning. And it also means that every such click triggers things like dependabot and renovate to file PRs for downstream libraries.

[telegrapher]

Hello!

I think that tagging a 1.0.0 may need a bit of planning, because if you follow semver, you're establishing a stable API.

But to start tagging 0.x.x releases shouldn't be problematic, since there is no commit to a stable API, and our go.mod files will be way nicer :)

[djmitche]

In a practical sense, I don't know if there's a difference. If 0.1.2 breaks API compat with 0.1.1, that's just as disruptive as v2 breaking with v1, if not a bit worse since automated systems can't tell that it's a breaking change.

My advice is, don't be afraid of breaking changes. The app I work on day-to-day is at v41. It's just a clear signal to your users :)

[davecheney]

I don't expect the library to be v1 ready any time soon. sorry. I'd prefer not to do the v1, v2, v44 game as it serves little utility and adds the overhead of the go modules v2 nonsense.