27

I have a couple of projects which are developed and released on different branches, namely development and release. The process works pretty well but unfortunately it has some drawbacks and I have been wondering if there is a better versioning scheme to apply in my situation.

The main development happens on a development branch (i.e. Subversion trunk but it doesn't matter much) where team of developers commit their changes. After building and packaging artifacts, Jenkins deploys them to maven repository and development integration application server. This is a DEVELOPMENT-SNAPSHOT and basically is just a feature branch containing all developed features on one common branch:

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>D.16-SNAPSHOT</version>

When one particular business change is done and requested by QA team, this single change is then being merged to the release branch (branches/release). Jenkins deploys the resulting artifact to QA application server:

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>R.16-SNAPSHOT</version>

Then there's a release which happens via maven-release-plugin on the release branch version of software (which creates a maintenance tag/branch for quick bug fixing). (R.16-SNAPSHOT => R.16)

Development and release branches are currently being versioned as D.16-SNAPSHOT and R.16-SNAPSHOT respectively. This allows to separate artifacts in maven repository but creates a problem with different maven mechanisms which rely on standard maven versioning style. And this breaks OSGI versioning as well.

Now, how would you name and version maven artifacts in such a scheme? Is there a better way? Maybe I could make some changes to maven structures other than simply changing the versioning and naming schemes? But I need to keep development and QA (release) SCM branches separate.

Would a maven classifier of 'development'/'production' be a reasonable alternative?

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>16-SNAPSHOT</version>
<classifier>D</classifier>
Mike Minicki
  • 8,216
  • 11
  • 39
  • 43
  • Look at http://stackoverflow.com/q/11413624/7581. It seems that the best way would be to have versions like `16-R-SNAPSHOT`, and `16-D-SNAPSHOT`. Don't use the classifier. – itsadok Nov 22 '12 at 09:35

3 Answers3

2

As far as I know, a common naming extension for a release artifact would be just the name of the artifact, without any stuff, only the version specified. A development branch would have the same artifact name but with snapshot.

For example, take twitter4j. The artifact name of the release version is

twitter4j-2.5.5

Snapshot of their(his) development version

twitter4j-2.6.5-SNAPSHOT

That is the naming convention almost everybody uses and is recognized by most tools. For example, my Nexus repository can specify a policy to ignore development releases which basically means it ignores the artifacts containing -SNAPSHOT in their name.

EDIT: To your followup question:

Well, depending on your build tool, you can create your snapshots to have the timestamp or some other unique identifier. However, I have never heard of some branching logic being embedded in the artifact's name just so the continuous int server can distinguish it. From the artifact's perspective, it is either a release, or a SNAPSHOT, I don't see the benefit of embedding more logic into the name of the artifact just cause your Hudson allows yo to do so. To be honest, your release cycle seems OK to me, but it would require some fine tweaking of your maven tools. If you can't live with that I would suggest you to use a classifier instead of relying on the name as it is always easier to tweak the integration server than a lot of plugins that rely on standard naming convention. In conclusion, I believe you are on the right track.

Nikola Yovchev
  • 9,498
  • 4
  • 46
  • 72
  • 5
    Baba, your example is missing one crucial element - branches. This is only good when you have one source (branch) which you are making releases of (e.g. trunk). In my environment, QA branch doesn't contain all the development changes (hence different branches) just the ones that are ready to be QA tested and released. The release is made out of this QA branch, so R.16-SNAPSHOT becomes R.16 on release; just as you have pictured it above. – Mike Minicki Dec 02 '11 at 13:11
  • Following your edit, baba. That's not a branching logic per se, that's separating release candidate and development versions. As I have mentioned in my original post (as an edit), it's just a special case of a http://martinfowler.com/bliki/FeatureBranch.html (special, because all the features are developed there simultaneously). Nothing fancy, I suppose. Thanks for the words of encouragement. +1 for you. – Mike Minicki Dec 02 '11 at 21:54
1

I think you could simply the process by having only two types as far as maven is concerned

  1. Snapshot (In perpetual development)
  2. Releasable (with a version number that can be deployed to maven repository or production release)

I would handle your branching a little differently, If you look at the iterative/scrum development model your code should be releasable/shippable at end of a iteration/sprint

  • Main sub version trunk is where developers commit their code
  • At the end of the sprint/iteration branch the main trunk and called it release branch (there should not be a QA branch any code that is to be released is tested for quality)
  • Bug fixes should happen on the release branch and periodically merged back to main trunk
  • This way you can keep creating branches for a release and any bug fixes are committed to branch
  • Always make sure before creating a new branch from main trunk, It has all the merges from previous branches
Prasanna Talakanti
  • 2,354
  • 1
  • 16
  • 16
0

The release plugin from Maven supports branching. It appears to work by assuming that the branch is created to support the next version of your code.

Personally, I'm more inclined to use the versions plug-in, and explicitly set my Maven project's version numbers.

Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185
  • 1
    I use both, Mark (I'm bumping versions via versions plugin on bugfix releases). But I'm afraid you have read my question not paying attention to details. Thank you anyway. – Mike Minicki Dec 02 '11 at 21:59
  • Ok, I'll be more explict... Read the release plug-in documentation and see how it supports branching. My advice is to stop trying to fight Maven by creating parallel copies of the same version("D", "R", etc). Instead create a branch that is destined to be your next version. For example a branch of version 1.0 would be called 1.1-SNAPSHOT. – Mark O'Connor Dec 02 '11 at 23:18
  • 2
    Mark, I do have such branch - 'branches/release' which has "1.1-SNAPSHOT". That branch is getting released as 1.1. But I have a feature/development branch as well, which has to be marked somehow, because other software may need a dependency on a development version which is not scheduled for closest release yet. I can't forgo dev and qa branches as I have explained in the comment to Prasanna. What's more, I'm not fighting maven, this setup works well enough (maven supports string versions, you know; it's documented). I'm just looking for an even better way to handle such situation. – Mike Minicki Dec 02 '11 at 23:52
  • 2
    Understood, I feel your pain :-) I would not advise using the classifier. While it can be used for several purposes, it's objective is to differentiate between additional files attached to a Maven module (for example source or javadoc archives). My parting comment is that what you're really looking for is called a module "status" in an Apache ivy repository. Unfortunately this concept is not supported by Maven repositories.... – Mark O'Connor Dec 03 '11 at 14:41