RE: Checking for rocks up

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Hisham
> Sent: dinsdag 2 april 2013 15:55
> To: Lua mailing list
> Subject: Re: Checking for rocks up
> 
> On 2 April 2013 08:15, Tomas Guisasola Gorham <tomas@tecgraf.puc-rio.br>
> wrote:
> >
> >         Hi Hisham
> >
> >
> > On Wed, 27 Mar 2013, Hisham wrote:
> >>
> >> * Rock X has a new version 2.0, which is incompatible with previous
> >> version 1.5. Rock Y depended on rock X, but it didn't specify a
> >> version (or it was optimistic and asked for "X >= 1.0"). Rock Y
> >> doesn't have an updated version yet which is compatible with X 2.0.
> >> Now rock Y is broken.
> >
> >         I thought that a move from 1.5 to 2.0 is an upgrade (which can
> > include incompatibilities) while a move from 1.5 to 1.5.1 is an update
> > (which should only correct bugs).  LuaRocks could use a more strict
> > definition of the version number and provide a simple way to update
> > packages based on the third number.  The Lua team follows this rule,
> > thus it does not seem to break too much code around.
> 
> It's a great idea in principle, but each developer follows their own
> numbering logic (and you know how hard (if not impossible) it is to impose
> a policy like that to the Lua world at large). But yes, for rocks within
> an organization, for example, it would make sense. Now that we are talking
> about a revision/extensions to the rockspec format, an idea that just
> crossed my mind is that the rockspec author could mark in a release which
> range of previous versions it is compatible with. Then the burden of
> ensuring that the upgrade won't break would be on the rock author, and it
> would work fine within an organization. For example, when releasing
> version 1.5.4 the rockspec could include something like api_compatible=">=
> 1.5" and then an auto-update command could check that before doing things
> automatically. (We would need a very strict definition of being "API
> compatible" of course.)
> 
> How does that idea sound?
> 
> -- Hisham

My take (as a SemVer[1] advocate) would be to add a flag whether the version numbering is SemVer compatible. That would immediately take all the ambiguity out of the compatibility question.

Thijs

[1] http://semver.org