[Building Sakai] The trouble with SNAPSHOT

Zach A. Thomas zach.thomas at gmail.com
Fri Jun 21 08:12:21 PDT 2013


Hello, all.

I have been following the discussion about the "indies" on the TCC list, but I'm confused about this issue.

If your tool depends on an indie service, it seems the only way you would get yourself into trouble is if you depend on -SNAPSHOT of that service. That's because whenever you want to release, you want to switch over from -SNAPSHOT to the "official" release version of that dependency, which means you rely on the indie service to release before you can. Is that the situation we're in?

If that's the case, then I would say the problem is binding to -SNAPSHOT in the first place. If we imagine indies like any other third-party dependency (say, commons-logging) then we would simply depend on the the newest published release at all times. There would be nothing stopping us from releasing anything. If and when a new version becomes available, you could bind to the new version at your convenience.

SNAPSHOT is my least favorite feature of Maven. I think it's an anti-feature. It's meant to make it more convenient to work with artifacts that are changing every day. My view is, the APIs you use are generally stable (at least, they should be _somewhat_ stable), so hopefully they're not actually changing every day[1]. The other side of the coin is that when your release process is not painful, it's just as easy to put out a new release of some artifact and update your dependencies as it is to use a SNAPSHOT. To put it in a nutshell, SNAPSHOT versions create more problems than they solve.

The one place I can see SNAPSHOT making sense is for artifacts within the module you're currently working on, because those really are changing multiple times throughout the day, and you have complete control them.

I'll make a small plug for Continuous Delivery at this point[2]. Maven's versioning insanity makes continuous delivery almost impossible. A reminder: the Java runtime doesn't care about version numbers. It only cares whether a) it can load the classes you're referring to and b) it can make the calls on those classes that you're asking it to make (i.e. the method signatures are correct). Our versioning problems are completely an artifact (pun intended!) of Maven's peculiarity.

What am I missing about this? Is it actually more complicated than I think?

Zach

P.S. I hate -SNAPSHOT

[1] If your APIs are stable but your implementations need to change frequently, that's fine: you should version your implementation separately from the API. The impl doesn't have anything depending on it directly, so it should be free to release as often as it wants/needs.

[2] http://aeroplanesoftware.com/blog/2013/03/26/continuous-delivery-equals-equals-awesome/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130621/48ce55ee/attachment.html 


More information about the sakai-dev mailing list