-
Notifications
You must be signed in to change notification settings - Fork 214
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
Assigning updates to major and minor releases #945
Comments
Excellent question. We discussed this a while ago, see #424 (comment) and also #665 (comment). If any new modules get into the master branch, then we release v0.4.0, else we just do a v0.3.1. The advanced branching strategy with backports and stuff was trialed in upstream GMT for a while during GMT 6.1.1 and was a bit of a chore. Probably don't need it until PyGMT reaches v1, but happy to revisit this topic |
@weiji14 That makes sense for how to determine if it's major or minor release. I think PyGMT is small enough that these releases won't have much in the way of breaking changes (we hope) to necessitate someone using a patched older release. Thanks for clearing this up, I didn't want to merge any PRs that have major changes only to find out I should have waited until after v0.3.1 is released. |
Just to make it clear, the version number is major.minor.patch, so:
|
Can we close this? Or is there anything we need to add to the MAINTENANCE.md? |
Might be good to bring up your comment at #941 (comment) here:
I can add it to the PR at #907 which is updating the 'Releasing' section in MAINTENANCE.md |
Sounds good. Then I need to remove the "enhancement" label from PR #952, and maybe declare it as a bug. |
So semver v2.0.0 at https://semver.org/spec/v2.0.0.html says:
Is an 'enhancement' always considered a new functionality? I'm thinking whether we could just bump the minor version if there is a 'feature' added? I.e. have just:
but not quite sure if my interpretation of semver here is correct. |
I think it's pretty subjective. Looking at the previous changelogs, most of the "enhancements" are adding new aliases to existing modules, or allowing more data types as input or output. They can all be declared as bugs 😄 |
As I understand the versioning system, a minor release will cover relatively minor changes (documentation updates and bug fixes are the examples that come to mind), while major changes, primarily new modules being wrapped, will be covered in the major releases. How do we control which release a given pull request/merge applies to? I'm assuming we'll release a v0.3.1 sometime in the next few months that will cover minor fixes and updates, but pull requests that add functions like
rose
andsolar
will be included in v0.4.0 sometime after v0.3.1 (or v0.3.2). Since there is just onemaster
branch, how do we control what will be included on a given release, and how do we withhold major updates from minor releases?The text was updated successfully, but these errors were encountered: