Skip to content
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.

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

Improve versioning of pgsphere #20

Closed
vitcpp opened this issue Jun 23, 2023 · 5 comments
Closed

Improve versioning of pgsphere #20

vitcpp opened this issue Jun 23, 2023 · 5 comments

Comments

@vitcpp
Copy link
Contributor

vitcpp commented Jun 23, 2023

Introduce releases

@vitcpp
Copy link
Contributor Author

vitcpp commented Jul 7, 2023

Dear All, I would like to agree on versioning of pgsphere:

  • In general, we should follow some principles described in https://semver.org/
  • Major number is for API incompatible changes.
  • Minor number is for API backward compatible changes (old user sql should work with newest pgsphere).
  • Patch number is for bug fixes (API is untouched).
  • Mark each version with annotated tag like v1.2.0

What I'm concerned, now we increment only the third number (patch number) for those changes that include API changes. I guess we should increment minor number in this case. But if we decide to increment minor number on each API small change this number may become too big.

One more question - should we increment minor or patch number each time when merging a new PR or introduce release plan?

Another issue is an optional compilation of some parts like healpix. I do not exclude that some new optional compilation will appear in the near future. I think it should be the user responsibility how to compile. The version number should not reflect how pgsphere is compiled. I see the only issue - upgrade scripts. I guess we may implement some query function that returns the list of compiled features. It may help upgrade script to decide what to do.

I appreciate any comments, thank you!

@vitcpp
Copy link
Contributor Author

vitcpp commented Jul 7, 2023

It seems this issue is a duplicate of #9. Closing it.

@vitcpp vitcpp closed this as completed Jul 7, 2023
@esabol
Copy link
Contributor

esabol commented Jul 7, 2023

It seems this issue is a duplicate of #9. Closing it.

I didn't see these as duplicates, but I'm ok with combining them. I thought this issue was for releasing new versions at https://github.com/postgrespro/pgsphere/releases. I thought issue #9 was going back in the commit history of repository and tagging old releases.

@vitcpp
Copy link
Contributor Author

vitcpp commented Jul 7, 2023

Well, I thought that it is a single complex problem with versions. Furthermore, there were some talks about producing release artifacts. It is why I decided to have the single issue for discussion. Anyway, I have no objections to reopen this Issue.

@esabol
Copy link
Contributor

esabol commented Jul 7, 2023

Well, I thought that it is a single complex problem with versions.

Yes, I agree with that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants