Backwards compatibility for shared desktop ontologies?

[Sebastian Trüg]

On 05/17/2011 12:48 PM, Stephen Kelly wrote:
> Sebastian Trüg wrote:
> 
>> 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.
> 
> Yes, the freeze is there to resolve these issues, as I wrote too, but if 
> such a big break appears on the day of freeze (a week before beta tagging) 
> after hibernating in a branch for 5 months, then *something* is broken. 
> That's just my opinion. 
> 
> I don't think having a 'Major feature freeze' and a 'Minor feature freeze' 
> is a sensible thing to do, but KDE developers should keep in mind that they 
> should introduce breakage or potential breakage months before freeze. So 
> there's probably no structural or scheduling solution, but only a community 
> one.
> 
>> 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
> 
> How could reverting it not be possible? It seems perfectly possible to me. 
> It's just a revert in kdelibs and kdepim-runtime.
> 
>> , 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.
> 
> Right. 3 of the solutions I proposed (the ones I prefer) are to hack rcgen.
> 
> Are none of the solutions I proposed acceptable?
> 
>> 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.
> 
> Ok.
> 
>>
>> KDE-PIM < 4.7 is another problem as it does not build against kdelibs
>> 4.7. But then again: who does that? 
> 
> Packagers apparently. They've raised the issue on the mailing list and on 
> IRC. Either KDE makes guarantees or KDE does not make guarantees.
> 
>> 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?
> 
> A release alone doesn't make it usable for everyone. While most are happy 
> with it, some are not. See this comment on my blog: 
> http://steveire.wordpress.com/2011/05/15/kde-pim-4-6-rc1/#comment-2206.
> 
> The comment is too vague to take any action, but it shows that people do 
> still have issues on the new stack. 
> 
> The fact is that the new platform does not work for everyone and does have 
> bugs and regressions, and people will want to use old versions of kdepim 
> with new kdelibs. 
> 
> The release is a development milestone less than a bugfix milestone.
> 
> Apparently I was not correct about kdepim4.4 working with kdelibs4.7, so 
> that is relevant.
> 
>> 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.
>>
> 
> Ok, this looks like the list I created, but with different numbers, which 
> can only add to confusion. Your (1) is my (5). Your (2) is my (3) or (4), 
> depending on what you have in mind. 
> 
> As I said, I'd be fine with my (2), (3) or (4). You say my (2) is not a good 
> idea because it is only relevant to rcgen. That leaves my (3) and (4). What 
> solution do you propose? When can we expect a fix to be written, reviewed 
> and tested? Keep in mind that beta 1 tagging is supposed to happen on 
> Thursday.

Like I already said: patching rcgen seems like the best solution to me
and that is so trivial I can have finished it today.

Cheers,
Sebastian