It depends what your trunk represents.
If you use the unstable trunk methodology, your trunk version will be whatever your future version will be. For example, If your last release was 4.9, your trunk will be 4.10 or maybe 5.0 depending what you plan to call the next release after 4.9.
Maven and Ivy have differing ways to refer to preliminary revisions. In Maven, preliminary revisions are SNAPSHOT revisions. They have their own repository. With SNAPSHOTS, Maven automatically downloads the latest version even if the user has a previous SNAPSHOT revision. When a jar is in the Release repo, Maven doesn't automatically download a newer revision if the user is using an older revision.
Maven will integrate with your revision control system, and automatically update the pom.xml
to change the version to a non-snapshot number.
I am not a big fan of that. We test particular Subversion revisions. They go through a series of tests. First, Dev will test. When they are happy, they pass that Subversion revision to QA. QA tests, and when they are happy, they send that revision to UAT. When UAT is happy, I want that particular revision to be my official release and I want to tag that one. In Maven, I am suppose to let Maven do the checkout, update my pom.xml, do a new build, deploy that new completely untested jar as my official release, and then tag my release.
In Ivy, the jar has a status associated with it in the ivy.xml
file:
- integration: revisions builded by a continuous build, a nightly build, and so on, fall in this category
- milestone: revisions delivered to the public but not actually finished fall in this category
- release: a revision fully tested and labelled fall in this category
I actually like this way much better. I don't have to change the revision. I don't need a second repository for snapshots, etc. It's clean and simple. Unfortunately, it's not compatible with Maven's methodology. I can't imagine things being that different with Git and Subversion is the way Maven works. In either system, you must create a new revision with a new non-snapshot pom.xml. In ether system, you must rebuild the jar. In either system, you must let Maven handle the tagging.
We do the following:
- We use Jenkins as our CI system.
- Most of our projects use Ivy and not Maven for historic reasons.
- When I build a jar, I create two POMs from the
ivy.xml
. I create apom-snapshot.xml
and apom.xml
. We have a special<jar.macro>
task I defined that is almost 100% compatible with the normal<jar>
task. Except this task produces apom.xml
, apom-snapshot.xml
and the jar with the Maven information embedded in it. - We use the Jenkins Promoted build plugin with two defined promotions. One uses the
pom-snapshot.xml
to deploy the jar to the Maven snapshot repository. The other uses thepom.xml
to deploy the jar to the Maven release repository. Developers promote the jar to the snapshot repo (some projects automatically do this with every build). When we have an actual releasable jar, we promote the jar to the Maven release repository. It also will tag that particular build as the actual release.
That means our branches do both the snapshot and release versions of our jars. We get to pick and choose which Subversion revision (actually which Jenkins build) is our official release build.