Fabrizio Giudici is a Senior Java Architect with a long Java experience in the industrial field. He runs Tidalwave, his own consultancy company, and has contributed to Java success stories in a number of fields, including Formula One. Fabrizio often appears as a speaker at international Java conferences such as JavaOne and Devoxx and is member of JUG Milano and the NetBeans Dream Team. Fabrizio is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Thoughts About Versioning, Specifically "SNAPSHOTS"

11.18.2009
| 5026 views |
  • submit to reddit
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?
Published at DZone with permission of Fabrizio Giudici, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mladen Girazovski replied on Thu, 2009/11/19 - 8:11am

I think that SHAPSHOT releases is not a good thing and they should be avoided (thats also the recommendation from Maven2, Artifactory doesn't accept SNAPSHOT releases per default config), a SNAPSHOT is per definition the opposite of a release.

Yannick Menager replied on Thu, 2009/11/19 - 8:45am

SNAPSHOTS are *very* useful when you have people who want/need to use your "work in progress" code, and are willing the trade-off of having code that changes all the time, with no guarantees of quality, reliability, or even that it works at all.

Your above example is a bad one, since you're talking of a paying customer, which generally wouldn't be willing to get broken code. In that scenario you'd generally do a branch from the last stable release, and create a bugfix release from that branch

Tipical scenarios for using SNAPSHOT would be:

TEAM 1 is working on some project, and is a few weeks away from having a working release

TEAM 2 needs to interact with the project from team 1, but don't want to be twiddling their fingers for a few weeks while waiting for the release

Using a snapshot build, they get the code they need now, and using a dependency management framework like Ivy or Maven, as well as their own CI, they can immediately see when changes in TEAM 1's project break their code

 

Fabrizio Giudici replied on Thu, 2009/11/19 - 10:43am

SNAPSHOTS are *very* useful when you have people who want/need to use your "work in progress" code, and are willing the trade-off of having code that changes all the time, with no guarantees of quality, reliability, or even that it works at all.

That's right - but especially for a small Mavenized project, is it really much simpler than tell people to clone the repo and make a build themselves?

Marc Ende replied on Thu, 2009/11/19 - 5:11pm in response to: Fabrizio Giudici

 That's right - but especially for a small Mavenized project, is it really much simpler than tell people to clone the repo and make a build themselves?

I think it'll be easier to provide development releases for these people. These development-releases could also be nightly builds or something like this. Not everyone likes to build libs from scratch. I've got several projects I'm working on and in all projects I'm working with snapshots and releases. There are several projects which are huge and several people/teams are involved. In this case you can't work without snapshots. Two other projects I'm working on are simple websites. But I use the snapshots also in this case. Snapshots are only used for development on the local system. After testing and everything is working correctly it's released and deployed on the live-server. I think using SNAPSHOTS and releases are just a point of personal interest and need some discipline (if you want to use it).

Fabrizio Giudici replied on Fri, 2009/12/04 - 6:14am

In the end, you convinced me and I've resumed the Hudson jobs to deploy the snapshots. Thanks for the feedback.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.