How to perform major version updates, using multiple branches... about axion-release-plugin HOT 23 CLOSED

i have a another flavor of the same issue. We released 1.0.0. I want the next release to be 1.1.0 and so I want our builds to be 1.1.0-SNAPSHOT but instead, the builds are 1.0.1-SNAPSHOT. Our version strategy is
increase first digit for major/possibly breaking change release
increase second digit for compatible change release - this will likely be increased every month per our release cycle
increase third digit for hotfix/patch release.

Seems like an option is needed to indicate which digit to increase. Is that possible?

Updated comment....
Figured out a solution by adding the following property into the projects gradle.properties. This will take care of most all of my build scenarios asked for by my CM team. After each release, this file is updated to the next version number. Maybe that defeats the purpose of this plugin, but it will work for us.

release.forceVersion=1.1.0

Updated comment...
Actually this is not going to work for us. I am researching alternatives. I would like to have the forceVersion only contain the releasing version like 1.1 but not the final 0.

from axion-release-plugin.

I am aware of this issue, still haven't figured out how to make it possible past forcing version like you do (via gradle.properties). the problem with this approach is, that we start committing files into repository. I wonder if it's possible to do it without hard-coding version.

from axion-release-plugin.

I do understand your commit concern. Using the GIT tags to determine is one really nice benefit of using this strategy - no code changes to support versioning / releasing.

However, I don't think it is awful to require a code change (commit), when you desire to change the next major/minor version number..

This approach would seem possible, and is still programmatic / deterministic -- just like your initialVersion property... Add an new, optional property called nextVersion. Because you are using "semantic versioning" -- it should be very easy to determine if one version number is older (less than) or newer (greater than) than another other.

So the logic to determine the next version would be quite simple...

• Using your current logic to get the previous tag
  • The previous tag is greater than the "nextVersion" property
    • Continue using the previous to generate the next version number
    • Ignore the nextVersion property
  • The previous tag is less than the the "nextVersion" property
    • Use the nextVersion property to generate the next version number

So, if you never want to tweak the "version number" and use the GIT tags, you never need to change your code -- and use your plugin as you originally designed it.

However, if you NEED to bump the version, you change the code (build.gradle) to provide the next version number.
- Since this changes would probably always be done on branches, I would think it would be very analogous to the way that Maven works.
- And we get to keep your original check-in-less version management on each branch

I hope this is not complete rambling, and is helpful.

from axion-release-plugin.

I like this idea. I will probably get some more thoughts on it as i start coding, but i really like how simple and unobstructive it seems :)

There should be some other way to say "hey, bump minor version, will you?" as well, this should all go in one task though.

from axion-release-plugin.

How about introducing concept of next version tag? Here is an example of how it could work:

$ ./gradlew cV
1.0.0-SNAPSHOT
$ ./gradlew release
$ ./gradlew cV
1.0.0
$ git add . && git commit -m "change something"
$ ./gradlew cV
1.0.1-SNAPSHOT
$ ./gradlew markNextVersion -Prelease.nextVersion=2.0.0
$ ./gradlew cV
2.0.0-SNAPSHOT
$ git tag
release-1.0.0 release-2.0.0-alpha

There would be a separate task i.e. markNextVersion that would create new tag with -alpha suffix. This tag could be then deleted (optionally) when releasing full version. When reading version, axion would treat -alpha tags only as marker of next iteration, and so append -SNAPSHOT to it.

One thing i am not sure is how jgit handles commits with two tags, which probably would happen a lot, as i imagine markNextVersion would get called right after release. Maybe there should be a mandatory, empty marker commit.

There should also be task for removing next version marker.

from axion-release-plugin.

@toddcscar you can create own formatting via custom versionCreator - it's a closure that is applied to create version. See README for how to implement it, but my guess is that you could go with something like:

{version, position -> "${version.majorVersion}.${version.minorVersion} }

This will print 1.0 instead of 1.0.0.

from axion-release-plugin.

You idea seems to work OK.. That is the behavior I'm looking for... Ship it! Thanks!

from axion-release-plugin.

Not to be a pain, I'm very grateful for your work.. But when do you think you will have this feature available? I have a week or two window to get this solution in place. Thanks again for your help.

from axion-release-plugin.

I started work already, i would like to be done with it after weekend - hope its okay?

from axion-release-plugin.

That would be perfect. Thanks again.

from axion-release-plugin.

I just pushed version with next-version support to development branch, could you take a look at README to see if it suits your needs?

from axion-release-plugin.

I looks like it should do the right thing... If you have everything checked in the dev branch - I will give it a test this morning. Thanks for the quick turn-around

from axion-release-plugin.

Maybe I jumped the gun, but I wanted to give you some feedback since you have been so helpful...
I think the "API" (interaction) will be perfect -- I just wanted you to know it was not doing what I expected...

I hope we are on the same page --- but the last currentVersion invocation should have been 1.7.5-SNAPSHOT, not 1.7.6-SNAPSHOT, since I did not release anything (only committed changes)

Very, very close... almost there!!! Thanks, Phil

phillipbeiler@ubuntu:~/workspace/publish-example$ gradle cV
:currentVersion

Project version: 1.7.2-SNAPSHOT

BUILD SUCCESSFUL

Total time: 4.648 secs
phillipbeiler@ubuntu:~/workspace/publish-example$ gradle markNextVersion -Prelease.nextVersion=1.7.5
:markNextVersionTask
Creating next version marker tag: release-1.7.5-alpha
Pushing all to remote: origin

BUILD SUCCESSFUL

Total time: 4.963 secs
phillipbeiler@ubuntu:~/workspace/publish-example$ gradle cV
:currentVersion

Project version: 1.7.5-SNAPSHOT

BUILD SUCCESSFUL

Total time: 2.88 secs
phillipbeiler@ubuntu:~/workspace/publish-example$ echo "" >> build.gradle 
phillipbeiler@ubuntu:~/workspace/publish-example$ git commit -m"new" -a
[release/1.7 9c9ff2e] new
 1 file changed, 1 insertion(+)
phillipbeiler@ubuntu:~/workspace/publish-example$ gradle cV
:currentVersion

Project version: 1.7.6-SNAPSHOT

BUILD SUCCESSFUL

Total time: 5.156 secs
phillipbeiler@ubuntu:~/workspace/publish-example$ 

from axion-release-plugin.

You are right, it should not work this way - simple fix :)

from axion-release-plugin.

@philbeiler done, now version won't be changed unless you perform a release

from axion-release-plugin.

I'm pretty sure this is working just like I needed it to... I have tested in on multiple projects and it seems perfect. Thank you so much for the rapid turn around on this new functionality.

I will let you close the ticket - as I assume you will merge the code into master.. Thanks again.

from axion-release-plugin.

Great, i been waiting for your confirmation :) I will create PR, merge and publish it right away as 1.1.0 version (i feel it introduced a major feature not present before).

from axion-release-plugin.

Quick question.. Does the markNextRelease actually push the tag to the repository? I'm thinking it does not. I ran the command "markNextRelease" locally - and currentVersion is returning the correct value; but all of my Jenkins jobs are producing the wrong version.

I looked in Stash (my GIT host) and the tag was not there. I did a push --tags from my machine and now Jenkins and I are much happier!!

If the code is not, I think it should push the tag - just like the release task does. Thoughts?

from axion-release-plugin.

It should work:

if(!localOnlyResolver.localOnly(repository.remoteAttached())) {
        repository.push()
}
 else {
       logger.quiet("Changes made to local repository only")
}

But i will take a look at it later.

from axion-release-plugin.

OK. I will pay more attention next time!

On Wed Feb 04 2015 at 10:23:33 AM Adam Dubiel [email protected]
wrote:

It should work:

if(!localOnlyResolver.localOnly(repository.remoteAttached())) {
repository.push()
}
else {
logger.quiet("Changes made to local repository only")
}

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

from axion-release-plugin.

I tested it and it seems to work fine for me - do you still have this issue?

from axion-release-plugin.

Sorry for not responding sooner... but I finally had a chance to get back to this today and it worked as you expected. Thanks again for your work. (FYI and playing with sphinx and reStructuredText today - thanks for the indirect tip!)

from axion-release-plugin.

No problem :) If you have any other issues/requests let me know.

from axion-release-plugin.