Home » Software Development » Project Versioning With Rultor

About Mihai Andronache

Mihai is an experienced Java and JavaEE developer. His main interests are: clean OOP, code maintainability and testing. He is the creator of http://comdor.co and http://charles.amihaiemil.com"

Project Versioning With Rultor

All of my projects, libraries or applications, are published on Maven Central. In case you don’t know how that works, I’ll tell you in short: it’s a nightmare.

Of course, I had to go through those steps one or two times but then I realised I might as well let Rultor do all that work for me since I was already using it in order to keep the master branch read-only and automate the merging of Pull Requests. Here is how the release process can be automated elegantly – I followed pretty much the same steps.

Project Versioning

Tom & Jerry – Mouse Cleaning, by William Hanna and Joseph Barbera

Now, when it comes to versioning, I use the classic x.y.z scheme: incrementing z means the release is containing mostly bugfixes and small features, incrementing y means that it’s containing some big features and incrementing x means that the release is not backwards compatible with the previous ones. Naturally, I want the coordinates in my repo to be automatically updated (for instance, if the new version is 0.0.3, the version in pom.xml should become 0.0.4-SNAPSHOT, the next development iteration).

While Rultor can build and send the artifact to Maven Central, as well as create a tag (“release”) in the Github repo, it has absolutely no idea about the actual versioning rules. This means that the version in pom.xml and any other links or coordinates to your artifacts are not updated.

After a few hours of work and successfully crashing Rultor once (sorry about that), I came up with this script which I use in all of my projects. It does a few essential things:

  • It performs the actual mvn build, specifically with the release profile. This is actually the step when the artifacts are sent to Maven Central.
  • It sets the next development version in pom.xml
  • It updates the <dependency> specified in the README.md
  • It updates the link to the fat jar, which is usually specified just bellow it.

This way, I can be sure that the latest release is referenced automatically wherever it’s needed and there are no stale/old links. What took the most in writing this script was figuring out how exactly rultor builds my release (on which branch) and how/when does it commit and push the changes to Github. Afterwards, I just specified the rcfg.sh file as a “release script” in .rultor.yml and it worked like a charm.

Published on Java Code Geeks with permission by MIhai Andronache, partner at our JCG program. See the original article here: Project Versioning With Rultor

Opinions expressed by Java Code Geeks contributors are their own.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments