Backwards compatibility for shared desktop ontologies?

Tue May 17 11:08:50 BST 2011

My comments as I am the one who introduced the break:

First off: I think the system does work. IMHO I am not the only one only
thinking about these dates shortly before they arrive. Thus, the hard
freeze is there to have time to fix issues like these. But that is just
my personal opinion.

As for SDO: the cardinality change was long due. I agree that it should
have been done sooner. But well, the harm is done. Reverting it is not
possible, the cardinalities are required. Introducing some hack in SDO
is not a good idea IMOH since it would only be there for the one tool,
namely nepomuk-rcgen. Thus, if anything was to be hacked, it would be that.

As far as dependencies go: KDE-PIM 4.7 does NOT depend on kdelibs 4.7
now since kdelibs <4.7 builds fine with SDO 0.7. Thus, it is perfectly
possible to have SDO 0.7, kdelibs 4.6.x, and kdepim 4.7 on one system.

KDE-PIM < 4.7 is another problem as it does not build against kdelibs
4.7. But then again: who does that? I know that is not a great argument,
but really, why would you update kdelibs and kde-runtime and friends but
not kde-pim, now that we finally have a kde-pim release with the rest of
kde again?
If someone wanted to do that there are two ways to make that happen:
1. Create another release of kde-pim <4.7 which introduces the mentioned
#ifdefs.
2. Patch nepomuk-rcgen to always generate both set and add methods.

With the above solution (both are very little code, 1. is of course more
trouble as it involves another release) the following is possible:

1. package SDO < 0.7, kdelibs < 4.7, and kdepim < 4.7
2. package SDO >= 0.7, kdelibs < 4.7, and kdepim >= 4.7
3. package SDO >= 0.7, kdelibs >= 4.7, and kdepim < 4.7
4. package SDO >= 0.7, kdelibs >= 4.7, and kdepim >= 4.7

Are any important combinations missing here?

Cheers,
Sebastian

On 05/17/2011 11:14 AM, Stephen Kelly wrote:
> 
> 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.
> 
> 