I realized today that I had made this nice flowchart about two years ago of how I decide when to add qualifiers and increment version numbers, but I never shared it anywhere very useful. This is heavily based on the version numbering scheme that Maven inherently understands. You should also checkout the excellent versions plugin for Maven that include some great utilities for upgrading your plugins and dependencies.

Recently I came across a company that is forking several open source Java projects. I saw they were making a mistake that I also made a few years ago and have since learned from. In Maven's distributed repository architecture project artifacts, like JAR files, are uniquely identified by a coordinate system composed of a group identifier, an artifact identifier, a version number, optionally a classifier, and a packaging type. For instance, the most recent version of the Apache Commons Lang project has a Maven coordinate (i.e. groupId:artifactId:version:classifier:type ) of commons-lang:commons-lang:2.5::jar . A few years ago, if I wanted to make custom changes to this project I would get the source, make my changes and then deploy the result to our private Nexus repository under a new groupId such as com.jaxzin.oss:commons-lang:2.5::jar . That might seem reasonable. Then a year later or so I tried something different and changed the artifactId like this commons-lang:commons-lang-jax...