DevHeads.net

Backwards compatibility for shared desktop ontologies?

Hi,

= Executive Summary =

The new Shared Desktop Ontologies version 0.7 changes in a backwards
incompatible way compared to version 0.6. kdelibs master already depends on
SDO 0.7. kdepim-runtime master also now depends on SDO 0.7.

kdepim4.4 still builds, because it happens to not use the backward-
incompatible generated code.

kdepim-runtime4.6 no longer builds against kdelibs4.7 and SDO
0.7.

I think this should block beta 1 tagging until resolved.

= Details =

SDO is used to generate C++ code for nepomuk in some way using the rcgen
tool (which comes from kdelibs). See

<a href="https://projects.kde.org/projects/kde/kdepim-" title="https://projects.kde.org/projects/kde/kdepim-">https://projects.kde.org/projects/kde/kdepim-</a>
runtime/repository/revisions/master/entry/agents/ontologies/CMakeLists.txt

and the code generated in your build directory for kdepim-
runtime.git/agents/ontologies

There are two issues to raise from this.

== First issue: backwards incompatibility ==

SDO 0.7 changes cardinalities of certain properties, causing the generated
code to be different to what it was before.

The code generated is source incompatible with what was generated in
previous versions, so the code in kdepim-runtime master was updated:

<a href="https://projects.kde.org/projects/kde/kdepim-" title="https://projects.kde.org/projects/kde/kdepim-">https://projects.kde.org/projects/kde/kdepim-</a>
runtime/repository/revisions/c6b255476c3c62ccdfb30a96e551af0e58d9c990/diff

This means that

a) kdepim-runtime master depends on kdelibs master, although the intention
with kdepim is to depend on the most recent kdelibs release or later.
b) as kdelibs4.7 depends on SDO 0.7, and SDO 0.7 can't be installed
alongside SDO 0.6 (afaik), packagers can no longer build kdepim4.4 and
kdepim-runtime4.6 against kdelibs4.7 because the code generated by rcgen
(which comes from kdelibs and processes SDO) is different. Methods like
setStreetAddresses have been removed and methods like setStreetAddress have
been added. From what I can tell, this change relates to optimization in
virtuoso queries.

Here's the relevant threads I can find about this:

<a href="http://thread.gmane.org/gmane.comp.kde.devel.pim/30489" title="http://thread.gmane.org/gmane.comp.kde.devel.pim/30489">http://thread.gmane.org/gmane.comp.kde.devel.pim/30489</a>

<a href="http://thread.gmane.org/gmane.comp.kde.devel.pim/30478" title="http://thread.gmane.org/gmane.comp.kde.devel.pim/30478">http://thread.gmane.org/gmane.comp.kde.devel.pim/30478</a>

<a href="http://thread.gmane.org/gmane.comp.kde.devel.pim/30474" title="http://thread.gmane.org/gmane.comp.kde.devel.pim/30474">http://thread.gmane.org/gmane.comp.kde.devel.pim/30474</a>

I see a few possible solutions.

0) Ignore it. Make it impossible to build/package kdepim4.6 against kdelibs
4.7 and SDO 0.7. This is the current situation afaik.

1) Revert the dependency bump. Make kdelibs depend on a version of SDO that
does not introduce backwards incompatibility breakage. This means reverting
c6b255476c3c62ccdfb30a96e551af0e58d9c990 and
f84602273ac22eb540a36a1681ed051e5d12c3f5 in kdepim-runtime and
2e1704ddfda6ae53ec2793129f2700601ac6f31b in kdelibs.

2) Add a new property to SDO like backwardCompatibleCardinalities = true
and make rcgen process that and generate *both* setStreetAddresses and
setStreetAddress if it is found.

3) Make rcgen generate *both* setStreetAddresses and setStreetAddress all
the time, and generate a KDE_DEPRECATED macro for the setStreetAddresses in
the case of cardinality=1.

4) Make rcgen generate *both* setStreetAddresses and setStreetAddress all
the time, unless it is invoked with --no-backwards-incompatible. Then use
that switch in the kdepim4.7 cmake file.

5) Use #ifdefs depending on the SDO version in and kdepim4.6, and calling
the correct generated method.

6) Make kdepim 4.6 depend on SDO 0.7 and patch it similarly to how master is
patched.

I use setStreetAddress as an example here. Hopefully you can appreciate that
it should be expanded to all properties in SDO in your head.

My preference is either (2), (3) or (4). If none of those happen though, we
should go with option (1) and revert the change.

I think this issue should block further tagging and releasing of KDE SC
until it is resolved.

Beta 1 is due to be tagged on Thursday, so packagers need to have this
resolved before trying to package this (which as you can see is already
happening).

== Second issue: communication fail ==

The second issue I have with this is that the commit making this change in
SDO was made on Decmeber 8th 2010 in a branch, and merged into master of
that repo on 15th of March.

The review request to depend on it and change the code came on May 11th (one
day before hard feature freeze). The review request summary does not mention
that it makes it impossible to package kdepim4.6 against kdelibs 4.7.

a) The consequences of this change were known in December 2010, as can be
seen in the commit message, but I had no idea about it until it appeared as
a review request on May 11th 2011, and didn't know the consequences until
two days ago.

I don't know if anyone else working on kdepim or packaging knew about the
impending change or its consequences. This is a big communication fail.
Concerns have been raised about this change on the packagers list and the
kdepim list but haven't been addressed yet.

b) The freeze is in place to get things like this sorted months before
release. However, having such a relevant change land only on the day of
feature freeze seems far too rushed, not thought through or communicated
well enough. Tagging of the first beta happens so soon after freeze that big
breaking changes like this should be avoided.

The final 4.7 release isn't until July, so I think there is time to fix
this. In that sense the hard freeze has served a useful purpose in bringing
this issue to light. Part of me says the system therefore works and nothing
needs to be changed, but the rest of me thinks that the rush and
communication fail is more generating more work for more people now (a
couple of dayss before beta tagging) than if this came to light in December
or January.

Does the system work or can something be fixed?

= Summary =

This issue is causing pain for packagers of kdepim 4.6 and kde sc 4.7, but
it is probably not extremely hard to solve. I have proposed some solutions.

Had this been raised 5 months ago instead of now, it would have probably
been a non-issue to find a solution.

All the best,

Steve.

Comments

Re: Backwards compatibility for shared desktop ontologies?

By Christoph Feck at 05/17/2011 - 06:14

On Tuesday 17 May 2011 11:12:50 Stephen Kelly wrote:
See bug 268595. The issue is known a bit longer :)

And as far as I have understood Nepomuk team, PIM code needs to be updated.
Therefore that review request/patch.

Christoph Feck (kdepepo)
KDE Quality Team