Change incremented part and prerelease from command line

[adamdubiel]

This is a proposal for solving problem discussed in #142

Problem

Creating versions like: 1.0.0-beta1 in a dynamic and generic way, without defining custom versionIncrementor.

Proposed solution

Add three new parameters:

./gradlew release -Prelease.increment=<major|minor|patch|prerelease> -Prelease.prerelease=<beta|rc|... -Prelease.finalize>

release.increment optional parameter has one of 4 fixed values: major, minor, patch, prerelease and determines which part of version should be incremented in this release:

./gradlew cV
0.1.0
./gradlew release -Prelease.increment=minor
0.2.0
./gradlew release -Prelease.increment=major
1.0.0

release.prerelease optional parameter can have any value (ascii, single word, no numbers) and adds prerelease modifier to version:

./gradlew cV
0.1.0
./gradlew release -Prelease.prerelease=beta
0.1.1-beta1
./gradlew release -Prelease.prerelease=beta
0.1.1-beta2

release.finalize optional parameter denotes that this release should not increment any numbers but remove prerelease values or replace prerelease with unnumbered new prerelease:

./gradlew cV
0.1.0
./gradlew release -Prelease.prerelease=beta
0.1.1-beta1
./gradlew release -Prelease.finalize
0.1.1

Behaviour

increment always defaults to the smallest part of version:

• patch if no prerelease
• prerelease if prerelease present

prerelease defaults to:

• empty if no prerelease
• current prerelease if prerelease available

./gradlew cV
0.1.0
./gradlew release
0.1.1
./gradlew release -Prelease.prerelease=beta
0.1.2-beta1
./gradlew release
0.1.2-beta2
./gradlew release -Prelease.finalize
0.1.2
./gradlew release -Prelease.prerelease=rc
0.1.3-rc1
./gradlew release -Prelease.finalize -Prelease.prerelease=final
0.1.3-final

[adamdubiel]

@levsa @szpak what do you think of it? I'm a bit concerned about the third parameter: finalize, somehow it feels cumbersome, but i could not come with any solution within the incremenet and prerelease parameters space.

[vbuell]

./gradlew cV
0.1.0
./gradlew release
0.1.1
./gradlew release -Prelease.prerelease=beta
0.1.1-beta1
./gradlew release
0.1.1-beta2
./gradlew release -Prelease.finalize
0.1.1
./gradlew release -Prelease.prerelease=rc
0.1.2-rc1
./gradlew release -Prelease.finalize -Prelease.prerelease=final
0.1.2-final

I'm confused by transitioning from 0.1.1 to 0.1.1-beta1 here. Shouldn't it be 0.1.2-beta1?

[adamdubiel]

Yes, you are right - it should bump patch as well. I will update the main description. BTW what do you think of this concept? I'm afraid it might be too complex, but on the other hand i see no simpler solution.

[vbuell]

This proposal introduces many new concepts and I'd say the logic for finalize may be tricky for end user... Alternatively we might try to to use the same ubiquitous language as we have in gradle configuration layer.

Assuming that we have scmVersion.versionIncrementer 'incrementPrerelease' in build.gradle:

./gradlew cV
0.1.0
./gradlew release
0.1.1
./gradlew release -Prelease.prereleaseVersion=beta1
0.1.2-beta1
./gradlew release
0.1.2-beta2
./gradlew release -Prelease.versionIncrementer=incrementPatch
0.1.2
./gradlew release -Prelease.prereleaseVersion=rc1
0.1.3-rc1
./gradlew release -Prelease.prereleaseVersion=final
0.1.3-final

[vbuell]

Few comments to the example above:

• In initial proposal -Prelease.prerelease=beta assumed that axion uses that value as prefix followed by number (1,2,3...). Sometimes the user may want something unusual (1.0.0-alpha, 1.0.0-beta, 1.0.0-internal, 1.0.0-ga). Using -Prelease.finalize works here but it will look hacky since it's not related to finalizing process and wordy. Instead of specifying a prefix it may be cleaner and easier to put a full prerelease version here. (That's why it's named as -Prelease.prereleaseVersion in the example above).
• -Prelease.finalize becomes redundant if we could change versionIncrementer temporarily. (-Prelease.versionIncrementer=incrementPatch in the example above)

[adamdubiel]

AFAIR versionIncrementer cna be changed on the fly already, so the syntax is here. The only missing thing would be adding the -Prelease.prereleaseVersion to make it all work (plus some more docs). I like this idea, it's simple and consistent.

Rationale behind mine proposal was making this mechanism easy to port to some kind of task name pattern matching like releaseMajorBeta. However it makes everything more complicated.

So, i'm leaning towards @vbuell proposal, especially that it is just a simple extension of existing settings and if we need something more sophisticated it will be easy to achieve in the future.

[szpak]

I wonder if it would be possible to combine -Prelease.increment=major and -Prelease.prerelease=beta (or an equivalent in the @vbuell proposal) to be able to switch from 0.3.1 to 1.0.0-beta.1?

[adamdubiel]

According to the proposal (and vbuell proposition) this is exactly what you gonna get:

./gradlew cV
0.3.1
./gradlew release -Prelease.increment=major -Prelease.prerelease=beta
1.0.0-beta1

Don't know about this . char, but in general prerelease syntax should be limited by SemVer spec.

[szpak]

I was rather thinking about potential implementation to support those mixes.

Semver is fine with dots. From their webpage:

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

The implementation could try to find a number at the end and increase it:

0.1.1
./gradlew release -Prelease.prereleaseVersion=beta.123
0.1.2-beta.123
./gradlew release
0.1.2-beta.124

[adamdubiel]

Yes, when running release on prerelease version it is incremented if possible. We already have incrementPrerelease version incrementer created by @vbuell which does this exaclty

[vbuell]

@szpak axion is already able to increment versions like 0.1.2-beta.123.

[szpak]

Great. I plan to use it soon :).

[hatavan83]

Hi @adamdubiel @vbuell could you please add more doc about pre-release in command line
I try it but not work

./gradlew cV
v0.0.2-SNAPSHOT
./gradlew release -Prelease.versionIncrementer=incrementPrerelease -Prelease.prereleaseVersion=RC.123 -Prelease.disableChecks -Prelease.dryRun=true -Prelease.prerelease=BETA
> Task :verifyRelease
Skipping uncommitted changes check
Skipping ahead of remote check
Skipping snapshot dependencies check

> Task :release
Creating tag: v0.0.2
DRY-RUN: creating tag with name: v0.0.2
Pushing all to remote: origin
DRY-RUN: pushing to remote: origin

[hatavan83]

Hi @szpak
Do you use prerelease successfully or not ? Could you please give me some guidelines if it is OK :)

[miikeat]

As far as i understand, you agreed in 2016 how the Prerelease and finalization should be handled but then in never got implemented!?!? is that so?
Is ther any other Solution to that Problem?

[gergely-sallai]

Hi,
Sorry to resurrect an old thread.
Is there any chance that this can be incorporated?

This is exactly what our release flow requires and would be a nice flexible API for this plugin too.
My current release flow:

• decide to work on some feature for 1.2.3
• feature is ready, seams OK too, mark it as an RC 1.2.3-rc1
• oh no, there's still some changes left, implement, mark as a new RC 1.2.3-rc2
• ok, everything fine, mark last RC as final: 1.2.3

(I need to keep track of RCs, and mark the last RC later as final because I have remote parties who can decide whether it is a go or no-go.)
The proposed solution would totally solved this!
example:

./gradlew cV
1.2.2

./gradlew release -Prelease.prerelease=rc
1.2.3-rc1

./gradlew release
1.2.3-rc2

./gradlew release -Prelease.finalize
1.2.3

[bgalek]

@gergely-sallai how do You feel about a contribution? :)