Over a million developers have joined DZone.

Thoughts About Versioning, Specifically "SNAPSHOTS"

DZone's Guide to

Thoughts About Versioning, Specifically "SNAPSHOTS"

· Java Zone ·
Free Resource

Delivering modern software? Atomist automates your software delivery experience.

As I converted to Maven, I started using its convention for naming versions, namely the idea of differentiating official releases from snapshot builds - the latter ones being tagged with labels such as 1.4.5-SNAPSHOT.

One of the advantages you get is that the release plugin can automate 99% of the tasks you have to perform when you release a new official build, by automatically tagging it as 1.4.5 and moving forward to 1.4.6-SNAPSHOT.

The other advantage is that you are clearly distinguishing an official build, supposedly subjected to a strong quality assurance process, from "hot" builds that can be made at every moment, typically for providing a hot fix to some customer. Maven also has got the good idea of making you able to differentiate (even physically) the release target repositories from the snapshot ones, making it possible to avoid excessive cluttering.

The multi-stage jobs that I build in Hudson the past summer were designed to use snapshots as daily build - there was a specific "Deploy" job that deployed all the artifacts to the snapshot repository.

Yesterday I removed it. In fact, I'm wondering whether it makes sense for my projects (I'm not questioning the fact that for sure it makes sense for a lot of people). As the conversion to Maven is not completed for all of my projects, and there could be different contexts, let me focus on one, which is jrawio.

This project has got a good functional, non regression test coverage - being a decoder for photos, tests got a decently sized (and growing) set of test files. I've adopted a "branch-per-feature" style of working, so the default branch is always stable. I'm using TDD for fixing issues and RFEs, so I only merge to the default branch when all the new tests pass and there are no regressions.

I've even got a Hudson job that is able to automatically perform the releases - the only thing that I still have to do manually is to update Jira and post a short announcement to the website.

Given that, why should I still need to deploy snapshot artifacts? Once the thing has got warmed up, I could decide a release schedule of a few weeks and always perform a release at the end of each period if I get even a single new thing committed in the default branch. If a customer makes an urgent request for a fix and I'm able to complete it quickly (e.g. yesterday I fixed one in a few hours), I could make immediately a new release, even if it was not planned.

At this point, I could differentiate between regular, planned releases and unplanned ones, the difference being only in that I could skip part of the manually tasks that are still required (merely, writing the announcement, because Jira should stay updated at fine grain).

What do you think?

Start automating your delivery right there on your own laptop, today! Get the open source Atomist Software Delivery Machine.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}