Backwards compatibility for shared desktop ontologies?

[Stephen Kelly]

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 

https://projects.kde.org/projects/kde/kdepim-
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:

https://projects.kde.org/projects/kde/kdepim-
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:

http://thread.gmane.org/gmane.comp.kde.devel.pim/30489

http://thread.gmane.org/gmane.comp.kde.devel.pim/30478

http://thread.gmane.org/gmane.comp.kde.devel.pim/30474

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.