You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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:
while:
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 justversion.next
available to bump patch digit by default (probably configurable by the user), but with the ability to override which value should be bumped withnext
(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.
The text was updated successfully, but these errors were encountered: