Versioning

[Ben Tatham]

We are currently switching from Subversion to Git, and we plan on using git flow.  So this plugin looks like a perfect fit for us.  But I do have some questions about versioning and how that impacts QA and the final release version numbers.

From what I can tell, release-start creates the release branch.  In the git flow world, it seems the correct thing to do is to give a build off that release branch to QA and if all is well, ship it.  However, the release branch is still a SNAPSHOT.  While at that point, we could just run release-finish and get the no-SNAPSHOT version, it seems odd to rebuild and ship a binary artifact that was not passed through QA, even if we do completely trust our build process.  

I've seen other blogs about maven/gitflow that discuss the release branch being changed to a -rc1, etc instead of keeping the SNAPSHOT.  Alternatively, add a fourth digit to an otherwise 3-digit version (effectively an rc, with the "rc" in the name, so it wouldn't be customer visible).  Yet another alternative would be to bump the develop middle version number and allow the release branch to own that major.minor version forever (effectively the same as the 4th digit as well, but the inverse and only using 3 digits).  

In all these cases, however, the release-finish would fail due to merge conflicts back to develop. 

I should note that our final artifact is more of a cellophane-wrapped style, since it is a binary image for an embedded product.  The customer must see the version number to know if they should upgrade their product or not.  

In general, we want to follow the mainstream - so what does the jgitflow plugin have to say about this issue?  

Thanks,

Ben

PS If the answer is always run release-start release-finish together, which certainly seems viable, it seems to negate the purpose of the release-branch from a gitflow point of view.  (But I guess when trying to reconcile to opposing systems (gitflow vs maven release), something has go to give...)

[Jonathan Doklovic]

I believe we have all the cases you mention covered.

You can do a release-start and use a releaseBranchVersionSuffix configuration to tack on something like "RC" to your version.

The plugin will be aware of this and make sure there are no conflicts due to versioning when merging back to develop on release-finish.

Also, there's a goal called "build-number" which will allow you to tack on an arbitrary build number to the end of the version when building the project but will not commit the changes. This is useful if you want to do a maven deploy from CI but don't want the version changes committed.

- Jonathan

[Ben Tatham]

The releaseBranchVersionSuffix looks like a great start, and it does indeed solve any merge problems since it does it for you.

But perhaps I'm missing something with respect to the process.  How do I release a non-SNAPSHOT to QA from the release branch without doing a release-finish?  This property does add the RC, but also keeps the SNAPSHOT version.  Do you use the maven-release-plugin on the release branch in the interim?  Perhaps modify the pom version manually with each "release" to QA?  

We're used to automating as much as possible, which I think is the goal of this plugin as well, so it would seem odd to me to have to modify the pom version manually, but perhaps that's the best solution right now.

--
You received this message because you are subscribed to a topic in the Google Groups "Maven JGit Flow Plugin" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/maven-jgitflow-users/CGuV7KRa7wM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to maven-jgitflow-u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Ben Tatham
Sr. Software Engineer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca

[Jonathan Doklovic]

In our builds, we use the build-number goal in the maven-jgitflow-plugin which will replace SNAPSHOT with a build number, and then we do a deploy....

jgitflow:build-number -DbuildNumber=${bamboo.buildNumber} -B

-- makes the version something like: 1.0-RC-build22

then our deploy goal looks like:

deploy -B -DskipTests=true

This happens on our release branch in our Bamboo builds under a job called "deploy to maven".

It always does a clean checkout and never commits anything, so we can run this job many time from the same release branch and get a new non-SNAPSHOT artifact with the build number in it.

When we are ready to release, we have another job that runs the actual jgitflow:release-finish which knows how to cleanly merge back into master/develop

To unsubscribe from this group and all its topics, send an email to maven-jgitflow-users+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Ben Tatham]

Thanks - I think that explains it.  There is still the issue of releasing a non-QA'd artifact to customers, but I think we can live with that by doing a simple sanity test and trusting the build tools to have a reproducible build.

To unsubscribe from this group and all its topics, send an email to maven-jgitflow-u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Doklovic]

Yeah, we also grab the commit SHA that bamboo checks the project out at and pass that as -DstartCommit={SHA} to the jgitflow goals.

This is just to ensure that jgitflow uses the same exact commit that bamboo has.

To unsubscribe from this group and all its topics, send an email to maven-jgitflow-users+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Ben Tatham
Sr. Software Engineer
Nanometrics Inc.
+1 613-592-6776 x254
http://www.nanometrics.ca

--
You received this message because you are subscribed to a topic in the Google Groups "Maven JGit Flow Plugin" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/maven-jgitflow-users/CGuV7KRa7wM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to maven-jgitflow-users+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Tatham]

So, to confirm (and sum up for archive trollers), here is how I understand the process you are recommending:

1) jgitflow:release-start to create the release branch

2) On Bamboo: "jgitflow:build-number install" to add a build number and do a build.

3) Give that build to QA

4) Fix any found bugs and commit to the release branch

5) repeat 2-4 until you're happy with the release

6) On Bamboo: jgitflow:release-finish to merge to master (and back to develop) and do a build.  Use -DstartCommit={SHA} to ensure you merge the same commit  that was QA'd and don't pick up any changes on the release branch after that (must check if you want to get those commits manually, before deleting the branch?)

7) Give the build from release-finish (with no QA on this actual build) to customers/production.

Correct?

To unsubscribe from this group and all its topics, send an email to maven-jgitflow-u...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Doklovic]

Yeah, that's the basic idea and should work for you.

I'm also doing a presentation at Atlassian Summit about how we integrate JGitFlow with our Bamboo builds at Atlassian. It's a little more complex, but we have everything automated in Bamboo.

I'll post the presentation here once it's available.

- Jonathan

[Matt Depue]

I'm trying to sort out the usage of build-number as part of this flow (or other flows).  Based off of the code, you can only add a new build number once per release branch unless you manually intervene and change the version to include SNAPSHOT (https://bitbucket.org/atlassian/jgit-flow/src/578237db8079ac70d55d4207bd03bee32bcddb58/jgitflow-maven-plugin/src/main/java/com/atlassian/maven/plugins/jgitflow/mojo/BuildNumberMojo.java?at=1.0-m3#cl-87).  Is build-number not intended to be used multiple times within a release branch?  If not, then what is the traditional use case for buildNumber?

[Jonathan Doklovic]

The build number is in effect a snapshot since every build has a unique number. The way it's intended to be used is to replace the -SNAPSHOT version with a -{buildNumber} version so you can deploy a non-snapshot version to your maven repository. This allows you to create "milestone" releases from each build. Also, the buildNumber mojo never commits the changes. You can commit them manually or with a separate task if you want to, but the intent is that you want to keep working on the branch and deploy multiple build number versions without commiting those versions to the repo.

For example, I'm working on 1.1-SNAPSHOT. I then want to give someone a build to test in some environment. I run buildNumber mojo which deploys a jar named "1.1-build1". We then find that there's a bug and commit a fix to the release branch, do another build (running the buildNumber mojo) and deploy "1.1-build2". We test that and it works. Finally we run a release finish with no buildNumber and no commits to give us a final "1.1" artifact which we can test/deploy to production.

[Matt Depue]

Jonathan,

Many thanks for the response.  I suppose I'm having a problem with the what I think the scenario is outlined in the second paragraph.  This is happening in milestone 3 FYI and here is a bit more detail:

1)  I'm working on develop and decide the code is feature complete and ready for a more thorough QA process

2)  I create a release branch using mvn jgitflow:release-start.  This results in the following:

  -A new branch release release/1.0 being created

  -pom version in release/1.0 being updated to 1.0-RC-SNAPSHOT (I have releaseBranchVersionSuffix set to RC).

  -pom version in develop is updated to 1.1-SNAPSHOT

  -current branch is set to develop

3)  Within release/1.0 branch I call mvn jgitflow:build-number -DbuildNumber=1.  This results in the following:

  -pom version in release 1.0 is updated to 1.0-RC-build1 (git status of pom.xml is modified).  Not: I'm not sure whether or not I should commit pom.xml into the release branch and probably more interesting is what happens if I need to change dependencies or other items in pom.xml (does only the version number not get merged in at release-finish?).

4)  Perform a mvn:deploy from release/1.0 branch (not sure if this matters or is necessary as long as package can get to QA).  This results in:

  -nexus repo contaings 1.0-RC-build1 artifacts

5)  Release to QA and there are required bug fixes...let's say

6)  Changes are made and multiple commits are made to release/1.0 until it is decided another release candidate should be sent to QA

7)  Decide code in release/1.0 is good so mvn jgitflow:build-number -DbuildNumber=2 is called.  This results in:

  -<<No change to pom.xml as the code looks for SNAPSHOT and the version has RC-buildx.  This is due to the following line of code (https://bitbucket.org/atlassian/jgit-flow/src/578237db8079ac70d55d4207bd03bee32bcddb58/jgitflow-maven-plugin/src/main/java/com/atlassian/maven/plugins/jgitflow/mojo/BuildNumberMojo.java?at=1.0-m3#cl-87).

My concerns are that either there is a bug in how build-number can be called multiple times in the same release branch or I'm misunderstanding the gitflow workflow.  I'm also curious about what happens if the pom.xml is changed in the release branch, e.g. to update a dependency.  Is the merge back during release-finish smart enough to only check for diffs in the version number?

Thanks,

Matt

[Jeffrey Bell]

The build-number goal has nothing to do with gitflow. It's targeted at enabling continuous integration servers like bamboo and jenkins to tack on a number that corresponds to the build's number.