[Building Sakai] The trouble with SNAPSHOT

[Steve Swinsburg]

Hi Zach,

You are on the mark. The trouble with SNAPSHOTs becomes particularly
evident when working in a version of code that is a moving target, ie
trunk. It is further compounded when using the indies since you are
dependent on a binary version of code rather than the source.

Imagine App A depends on App B. App B is moving fast and App A wants to
take advantage of a new API. App B has no regular releases so App A is in a
pickle unless App B has SNAPSHOT artifact deployed on a regular basis, ie
via continuous builds.
Suppose App B does have the SNAPSHOT releases but then development time is
pulled away to work on another project. App A now cannot release since it
binds to SNAPSHOT artifacts so you either need to get a stable release of
App B, which may not be stable since there are no dev resources, or re-work
your code to not use the new features. A mess.

These problems are solved by not depending on SNAPSHOT versions. It also
puts a project in a constantly releaseable state, assuming the code is
sound, because projects are no longer dependent on any other project in
order to roll a release. The old mantra of release early, release often is
also key here. We don't want months between releases of an evolving project
because everyone has to wait for a release of that project before they in
turn can release.

So yes, I dislike SNAPSHOT versions also.

I am attaching my proposal for adjusting the release process and scrapping
the indies, including SNAPSHOT version, which I wrote last month and sent
to the TCC. I was not at the conference so am not sure to what level it was
discussed. There has been discussion on the TCC list, I just hope we can
keep the momentum going and modernise our practices.

cheers,
Steve




On Sat, Jun 22, 2013 at 1:12 AM, Zach A. Thomas <zach.thomas at gmail.com>wrote:

> 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/
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130622/945387da/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cle-release-process-proposal.pdf
Type: application/pdf
Size: 106212 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130622/945387da/attachment.pdf