Request for Tagged Release

[CascadingRadium]

We've been using a fork of this repository and would like to periodically sync our fork with a stable release or tag. However, we noticed that the repository currently lacks any tagged releases. It would be helpful if the maintainers could tag a stable commit as v1.0 (or similar) to serve as a starting point for versioned releases.

[jmr]

We've been using a fork of this repository

If the fork you're talking about is blevesearch/geo, we'd like to get any fixes/additional functionality merged back here.

periodically sync our fork with a stable release or tag

Just creating a tag doesn't really solve anything. Are you expecting this to have some extra testing or something?

[rsned]

Probably something akin to the C++ https://github.com/google/s2geometry/releases. (vs running from wherever HEAD is at in the development process)

[jmr]

That was done so it could be packaged by Debian; they won't package a commit hash. The "extra testing" for the release is usually just "no one has complained about new code for a week or two".

Since go has its own package system, this doesn't apply.

A ~quarterly 0.x release could make it easier for people to know what version to grab and that they're not getting something that was just merged. It would be good to hear the original requester's reasons. @CascadingRadium

[CascadingRadium]

We maintain a pipeline for upgrading dependencies in our upstream projects, and our fork of this repository is one such dependency. Currently, the process of syncing our fork to the main repository involves tracking specific commits, which is cumbersome.

Introducing tagged releases would streamline this workflow. By referencing stable, versioned tags rather than individual commits, we can automate dependency upgrades more reliably and maintain better traceability. This practice aligns with common versioning standards and would benefit other consumers of the repository as well - as the go.mod for a user will have

require (
    github.com/golang/geo v1.0
)

instead of

require (
    github.com/golang/geo v0.0 <commit-hash>
)

[flwyd]

For the record, I don't think we're reading to commit to the API stability of a v1.0 release.
I think periodic 0.x releases would be useful. Among other things, they're easier for humans to visually inspect.

[alan-strohm]

I discussed this briefly with the C++/Java maintainers and they pointed out:

1. If we do this, we should find a way to communicate that the releases are go-specific and can't be compared across language versions.
2. Even noting breaking API changes between versions is challenging and not worth more than a best-effort attempt.