Transition from alpha to rc

[himslm01]

I'm looking for a little help with workflow.

Lets say I've been developing a component and I have done a markNextVersion to create an alpha tag release-1.0.0-alpha.

When I think the component is ready I would deploy it to the Quality Assurance team. That sounds like a release candidate. That should be a release-1.0.0-rc1 tag.

I already have scmVersion.versionIncrementer 'incrementPrerelease' in my build.gradle, but what would be the right way for me to have the -rc1 tag created?

I think I expected a makeReleaseCandidate task - but since there isn't one I must be missing something.
I've also failed to find any documentation on how incrementPrerelease was used in a workflow.

Could you point me in the right direction.

[adamdubiel]

There is no task for this kind of thing. What you should do instead is run ./gradlew release -Prelease.version=1.0.0-rc1. This will start the rc count. Subsequent releases in your configuration will result in bumping the rc version (rc1, rc2...). When you are ready to go with full version, you should once again use release task with forced version: ./gradlew release -Prelease.version=1.0.0.

[himslm01]

Thanks Adam.
Do you think there should be built-in tasks for those two actions?

[adamdubiel]

I think maybe not a task itself, but some kind of version incrementation strategies that would do this, which could be set per release run:

./gradlew release -Prelease.versionIncrementer=alphaToRc
./gradlew release -Prelease.versionIncrementer=rcToStable

If i understand correctly you would like to have all those steps automated and passing some forced version is not so convenient, as it requires human intervention and version parsing.

[himslm01]

I see where you're going.

Obviously, what I'm after is something that requires the least thought process and is the simplest to automate in a CI process.

Using your suggestion, following a usual development flow, we'd start 0.1.0 and release some snapshots

0.1.0-snapshot
0.1.1-snapshot
0.1.2-snapshot

We've finished most coding and convert to alpha calling the markNextVersion task with a release.nextVersion of 1.0.0.

1.0.0-snapshot

And then convert alpha to rc calling the release task with a specific versionIncrementer

1.0.0-rc1

release a few of those

1.0.0-rc2
1.0.0-rc3

When we're happy, release with a specific versionIncrementer to create the 1.0.0

1.0.0

Yes - if that workflow was possible without every build.gradle requiring tasks to get the current version, parse it, and add -rc1 or remove -rc* then I think I'd be generally happy ;-)

[jkrizanic]

I have also a need for the same flow.

But if you are happy with 1.0.0-rc3, and want to promote this to 1.0.0, you will do it probably from the same commit?

As I see a tag for 1.0.0 will be created, but current version returned by the plugin stays at 1.0.0-rc3.

Is there any way to get the released version, 1.0.0?

[levsa]

I too want to do a similar approach, e.g., first create a 1.0.0-rc1 tag, and later create 1.0.0 if the rc version passes all tests. Alternatively, create -rc2 etc first and then create the final release.

I've managed to write a task that does something like this:

    def removeRC = { version ->
        if (version ==~ /.*-rc\d+/) {
            version.replaceAll(/(.*)-rc\d+/) { all, allMinusRC -> "${allMinusRC}"}
        }
    }

    task releaseFinal {
         finalizedBy release
         doFirst {
            project.ext["release.version"] = removeRC(project.version)
         }
    }

    project.version = scmVersion.version

which works as far as creating the 1.0.0 tag.

But, after that, when running the currentVersion task, the plugin finds the last rc tag as the latest tag, and not the release tag. Is it possible to fix this? (Created issue #139 for this).

ps. I've also created a task to create the first rc automatically without need to provide the major version (possible by giving a major version incrementer and setting a project property to add the rc prerelease version).

[levsa]

Created pull request #142 for going to/from release candidates (although the 'createFinal' step still needs more work).

[ProTrent]

What happened to this and the pull request?

[ProTrent]

I'd like to have some way of setting the 'SNAPSHOT' value based on the branch... So 1.0.0-RC1 if I'm on branch 'release/*' vs 1.0.0-SNAPSHOT on another branch. Is that doable?

[adamdubiel]

Changing SNAPSHOT to any other string breaks the contract with Maven versioning style. -RC1 is actually a release (as in: kept indefinitely in artifact store), while -SNAPSHOT is just a snapshot (can be deleted).

So it looks like you would actually want to make a release for each commit in release/* branches? If so, why not make a release with custom version?

[ProTrent]

Is there a way to do it by branch or automatically? I'm trying to automate the release process and having to type in RC1 on a command line makes that harder. If it knows by the branch to use RC for the release branch it would be better.

…

On Tue, May 9, 2017, 4:02 PM Adam Dubiel ***@***.***> wrote: Changing SNAPSHOT to any other string breaks the contract with Maven versioning style. -RC1 is actually a release (as in: kept indefinitely in artifact store), while -SNAPSHOT is just a snapshot (can be deleted). So it looks like you would actually want to make a release for each commit in release/* branches? If so, why not make a release with custom version? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#135 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APzJ01jnFUJJoiIV4bZJNLJhSp22bM08ks5r4OJ9gaJpZM4IOZbv> .

[Bittuw]

Any updated?

[ProTrent]

Not sure, I stopped using this plugin myself, so best of luck!

…

On Tue, Jun 30, 2020 at 8:51 AM _Mr_Bin_ ***@***.***> wrote: Any updated? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6MTU4OFUTWOSDTSELJKHTRZH3XNANCNFSM4CBZS3XQ> .