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

Shortcut for next version bumped by major/minor/patch #138

Open
szpak opened this issue Oct 27, 2023 · 2 comments
Open

Shortcut for next version bumped by major/minor/patch #138

szpak opened this issue Oct 27, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@szpak
Copy link

szpak commented Oct 27, 2023

For commits after the release tag (e.g. v1.4.4), we would like to have the next version proposed with SNAPSHOT (e.g. 1.4.5-SNAPSHOT). Currently, it is required to write:

refs {
    branch('master') {
        version = '${describe.tag.version.major}-${describe.tag.version.minor}-${describe.tag.version.patch.next}-SNAPSHOT'
    }
...

while:

        version = '${describe.tag.version.nextPatch}-SNAPSHOT'    //doesn't work

would be more convenient (together the variant for minor and major).

Unfortunately, the naming (e.g. nextMinor) doesn't match the already using naming convention. version.next.patch would be better, but people might expect to have the patch number from the next version. WDYT about adding something lilke that?


As a bonus (might be a separate issues, if preffered), in that approach, having the patch version usually bumped, it could be useful to from time to time release the bigger library update (e.g. 1.4.4 → 2.0.0). With nextPatch (and others) it would be problematic on CI. Maybe there could be also just version.next available to bump patch digit by default (probably configurable by the user), but with the ability to override which value should be bumped with next (with Gradle property or anything sensible for the CI environment). WDYT?

Update. After thinking about that, the bonus part doesn't seem to be crucial as the release version is taken from the tag, so only the SNAPSHOT versioning is affected, which could be "easily" override with changing the plugin configuration in the feature branch (just for releasing snapshots) and removing the changes before merge to master, followed by the tag creation.

@qoomon qoomon self-assigned this Oct 29, 2023
@qoomon qoomon added the enhancement New feature or request label Oct 29, 2023
@qoomon
Copy link
Owner

qoomon commented Oct 29, 2023

Hi @szpak , thanks for the idea I probably would go for something like this:

  • ${describe.tag.version.next-patch}
  • ${describe.tag.version.next-minor}
  • ${describe.tag.version.next-major}

@szpak
Copy link
Author

szpak commented Oct 29, 2023

Sounds good @qoomon.

Btw, I assume that internally next-* will return "the version object", so I would be able to do: ${describe.tag.version.next-patch.major} (or similar), if needed?

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

No branches or pull requests

2 participants