8000 Request for Tagged Release · Issue #167 · golang/geo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Request for Tagged Release #167

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
CascadingRadium opened this issue Apr 29, 2025 · 6 comments
Open

Request for Tagged Release #167

CascadingRadium opened this issue Apr 29, 2025 · 6 comments

Comments

@CascadingRadium
Copy link

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
Copy link
Collaborator
jmr commented Apr 29, 2025

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
Copy link
Collaborator
rsned commented May 3, 2025

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

@jmr
Copy link
Collaborator
jmr commented May 4, 2025

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
Copy link
Author

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
Copy link
Collaborator
flwyd commented May 4, 2025

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
Copy link
Collaborator

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.

@CascadingRadium CascadingRadium mentioned this issue May 8, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@flwyd @jmr @alan-strohm @rsned @CascadingRadium
0