ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: proposal: a versioning repository
Date Fri, 17 Sep 2010 21:47:34 GMT
Hello Premek,

On 17 Sep 2010, at 15:21 , Premek Brada wrote:
> On 17.9.2010 10:24, Marcel Offermans wrote:
>>> This effectively ensures version-implementation consistency across all bundles
>>> by the given ACE repo instance, in other words, no nasty runtime errors / exceptions
>>> to type mismatches in wired bundles obtained from such a repository. Also, it
>>> the bundle programmer can be lazy and leave versioning chores to the repository
>> You rightfully put a smiley there, as not all semantic changes can be automatically
detected by tooling of course. However, I do like the idea a lot.
> That's correct, the versioning algorithm -> API -> tool handles syntactic changes
on public class elements only; OTOH, that is in line with the semantic versioning whitepaper
which deals mainly with the interface/type/syntactic changes and reserves the micro and qualifier
parts of the version identifier for semantic and internal changes.  (Leaving aside the issue
that detecting, classifying and versioning semantic changes properly is a lot more difficult


>>> - [if yes] How would you imagine/suggest such a thing should be integrated
>>>   into ACE?
>> As you know, currently ACE supports a REST like interface for OBR, so it would be
nice if we could integrate it at that level. Eventually we need to support adding bundles
to the OBR from the web UI so integrating it there would also be nice.
> OK, that's a plan already; I would be interested in putting together the signatures for
the REST interface. Any suggestions?  I haven't yet tried the web UI properly, will explore
that and try to come up with ideas.

The web UI as it is right now consists of 4 columns (artifacts, features, distributions and
targets). Dragging a local file into the artifact column could trigger an upload of that file
to the OBR, and go through your versioning tooling.

>>> We of course have an implementation, it extends the plain 
>>> interface to include versioning --
>>> see the attached pieces of code to get an idea how it works (there is
>>> about 0.5MB of libraries hidden behind this small interface). However, 
>>> this is our first cut and by no means an ideal solution.
>> Would you consider donating and supporting this?
> In principle, yes. We however first need to sort out intellectual property stuff and
get rid of some of the bugs we know about. 

Fair enough.

>>> PS: A sort of advertisement: we have a bundle versioning service at
>>> - you are invited to give it a try, I would be interested
in any feedback.
>> From the service on this website, I would like to get a bit more feedback about the
actual analysis. As a test I submitted different versions of the compendium bundle, and that
went well (in essence, the tool concluded that the versions were correct).
> What kind of feedback would you like to get?

I would like to see some kind of side by side comparison of the older and newer version and
any changes that were made to the newer version:

 bundle-1.0.0 <-> bundle-2.0.0 [was 1.2.0]

From there it would be nice if you could "drill down" from the bundle to its packages:

 bundle-1.0.0 <-> bundle-2.0.0 [was 1.0.1]
   package.a 1.0.0 <-> package.a 2.0.0 [was 1.0.0]
   package.b 1.2.0 <-> package.a 1.3.0
   package.c <-> package.c (changed)

From this level of detail, one could see the user forgot about the change in package.a which
lead to an incompatible API change, so a major version bump. You also see package.b was versioned
correctly, and that the private package.c has changed (but since those are not versioned,
you cannot say much more than that).

You could even drill down to class/method level.

Does this make sense?

Greetings, Marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message