Re: Checking for rocks up

[Jay Carlson <nop@...>]

On Apr 2, 2013, at 9:54 AM, Hisham wrote:

> On 2 April 2013 08:15, Tomas Guisasola Gorham <tomas@tecgraf.puc-rio.br>
> wrote:
>> 
>> 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.)

IMO one of the most common missing pieces of data models is subject, and by that I mean the entity making a particular statement.

I can write in a file

  This is api_compatible >= 1.5.

but the actual information you have to work with is

  Jay Carlson says, "This is api_compatible >= 1.5."

And you'll have to combine that with "I trust Jay Carlson's opinion" to get anywhere.

The source of the statement can be elided in single-authority systems; you end up with "the rock git repository says" implicit in front of everything. Then you get site-specific overrides, off-tree patches, ...and trying to work out *why* you believe statement X is impossible because you've erased all notion of situated statement.

This kind of thing is not exactly an everyday technology, but you may want to consider richer models for representing versioning even if you're going to use simple rules to collapse everything to axioms at the start of a run.

Jay
"Ontology is not the problem. Epistemology is the problem."