Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-measured-data-wg] Unexpected changes to OpenMDM API

It may be so with the particulars although I’d expect both AC and QC to chime in regarding processes and checks that should be in place in order to ensure everyone working with the codebase follows the same approach, for the benefit of all members of this working group. 

If documents exist regarding these points then I’d expect them to be clearly accessible directly from the mdmbl website, most likely at the Developer Resources section :-)

The original message has been sent to the mdmbl-dev list. 


Sent from my primitive Tricorder

On 9 Oct 2017, at 18:08, Ralph Mueller <ralph.mueller@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi -

I believe this is an email that is better suited for the dev.list of the Eclipse mdmbl project. 


Regards / Liebe Grüße,

Ralph Mueller

Managing Director, Eclipse Foundation Europe GmbH
Mobile: +49 177 449 0460
Office: +49 6251 8606413

Am 09.10.2017 um 15:24 schrieb Andres Almiray <andres.almiray@xxxxxxxxx>:

Hello everyone,

We’re trying to build a version of the web client by grabbing the latest sources. There’s a break in binary compatibility brought by
The getID/setID methods were migrated from Long to String.

Why is this a problem? Because the project version did not change. Have a look at the project repository at
The change was introduced by

2017-07-19 518738: Type of Entity-IDs (changed in api.base, api.default, api.ods)

It’s quite recent. Three commits later the repository was tagged with 0.7. 14 commits later it was tagged with 0.8 (on September 7th). Yet the project’s version is still set to 1.0.0.
So which is it? Is it 0.8? is it 1.0.0? Aren’t we supposed to be using semantic versioning for labeling project versions? If we are then the current state of the project is horribly broken. This “small change” should have prompted the project version to jump to 2.0.0-SNAPSHOT at the very least if semver is to be followed to the letter. If we’re not following semver, then what is it?

I ask then, what versioning scheme is in place and where do we get hold of the document that states it?

This commit appears to make a reference to bug ID 518738. Which issue tracker are we supposed to use? Eclipse’s bugzilla points to an Eclipse Neon & _javascript_ problem 
The mdmbl website points to Eclipse’s bugzilla if you want to report a bug or review bug reports.
The OpenMDM Jira instance doesn’t even reach that number

You never ever, let me repeat that, NEVER EVER use version ranges at any time, for whatever reason!

Their usage lead to unreproducible builds and other potential incompatibility issues. Granted, Mockito is a project that evolves very, very fast, they push releases at least once a month, and as great as they try to keep things tidy they broke binary compatibility by moving around private APIs between 2.6.x and 2.7.0. This could happen again. Matthias, you’re exposing the project and every developer that wants to build the project to potential problems just because you couldn’t be bothered to pick a fix version for a dependency. If you didn’t pick the version range at least you signed of the commit. Please do not do this. This problem should have been spotted in a code review.

Andres Almiray
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel

Tel: +41 61 228 94 44
Fax: +41 61 228 94 49


open-measured-data-wg mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

open-measured-data-wg mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top