Re: Checking for rocks up

[Hisham <h@...>]

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