Maven installs / deploys with Jenkins build number

Question

UPDATE # 1 9/18

My company decided to completely update the development / release cycle to match the growing number of developers.

The git process will look like a successful branching model with a few changes. Instead of developers having direct push access to the "development" branch, developers will need to fulfill a merge / pull request, requiring code verification and testing the base unit.

The version system will be Major.Minor.Patch, where Major versions mean backward compatibility, minor versions indicate new features and minor bug fixes, and fixes indicate critical fixes. This new version of the system will remove the Jenkins build number as useful information, but attach it to the deployed artifacts for historical purposes.

The "Development" industry will be monitored by Jenkins to create and deploy SNAPSHOT for our local Nexus, so developers have not yet released, but accepted features. The master branch will also be tracked by Jenkins to create and deploy release artifacts.

Release Process:

• Update POM version based on features released
• Git tag branch with new version
• Perform device, integration, and system testing.
• Build, obfuscate, and deploy release artifacts to our Nexus
• Upgrade the develop branch to Major.Minor ++ - SNAPSHOT for the new SNAPSHOT development.

ORIGINAL MAIL

I am trying to create a JAR library that is confusing, uses a dynamic assembly number based on the Jenkins / Hudson assembly, and deploys in its own Nexus sonata style.

My problem is that Maven install / deploy does not make changes to finalName, and installing a version with an expression like the one below is considered "bad practice":

<version>1.0.${buildNumber}</version> 

Although this is bad practice, it correctly installs / deploys artifacts with the proper version, both local and remote. The build number is based on a pair of profiles that are associated with the existence of the environment variable. The build number of the Jenkins build system is zero by default if this variable is missing:

  <profile> <id>static_build_number</id> <activation> <property> <name>!env.BUILD_NUMBER</name> </property> </activation> <properties> <buildNumber>0</buildNumber> </properties> </profile> <profile> <id>dynamic_build_number</id> <activation> <property> <name>env.BUILD_NUMBER</name> </property> </activation> <properties> <buildNumber>${env.BUILD_NUMBER}</buildNumber> </properties> </profile> 

We do not use SNAPSHOT versions, since any version that has been fixed and ported to Nexus is considered a tested release version.

Is there a “correct” way to install a version of Maven based on a dynamic Jenkins / Hudson build number that allows it to be deployed with this updated version?

Answer 1

The maven method says that the version only changes when you release the code, and that two consecutive assemblies of the same version should produce the same result.

In your case, you go against these two good practices.

If indeed every commit is a new version, then what you do does not sound terribly wrong (but it sounds funny to me). One of the drawbacks is that it doesn't seem like you are creating a tag from your VCS (which is another good practice).

I will be honest. I cannot believe that every commit is ready for release. I have never seen this, even in continuous delivery environments where each commit needs to go through a lot of automated testing, and sometimes the revision is rejected (perhaps for reasons of functionality or performance).