[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: koffice/libs/main
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2007-10-26 11:23:51
Message-ID: 200710261323.51613.cberger () cberger ! net
[Download RAW message or body]

On Friday 26 October 2007, you wrote:
> Well, you may be fine with people not being able to compile your plugins
> due to a version conflict, I'm pretty sure the average developer and
> certainly end-users have a different view on this topic. ;)
Then I just have to release a new version of the plugins set, like I am 
allready doing. What is better, you can't have the plugins or you will need 
to update the plugin packages after next release ?

> If we release/install headers we would state they are actually to be used.
> Which in 2.0 they simply are not since we already have quite some
> restructuring planned for the odf-module after the 2.0 release.
>
> This is a typical case where we *should* release early and often, but
> requiring compatibility just not good for KOffice.
How often do you think we will be able to release ? Six monthes is a minimum, 
and I am very skeptical wether KOffice have the ressource to currently have a 
six monthes release cycle, it will be more likely between 8 to 10 monthes. 
And I am not convince that a 2.1 released six monthes after a 2.0 will have a 
stable API/ABI. So then we are waiting an other year before being able to 
release plugins.

And being able to release plugins during the release cycle is the best way to 
one test new features before including them in an official release, for 
instance, it has allowed me to discover that the "red eye removal" tool was 
not good enough for being an official part of Krita, and that started 
interesting dicution with users to see how to improve it. And two, to have 
longer release schedule for the code base while keeping improvement on 
KOffice.

Plugins are not limited, and should not limited, to "external" development. 
It's also a tool for us.

> And I personally don't see this as a reason to delay the release.
Who speak of delaying the release ? Just keeping installing koffice 
development headers and everything needed to link. And stating that "We don't 
guarantee neither Binary Compatibility nor Source Compatibility between 2.0 
and 2.1". Just at this between <h1></h1> on top of our doygen documentation, 
I don't think anyone will start developing plugins for koffice without 
reading it.

> So, for you personally I think you have to choose between releasing your
> code with the official KOffice release, or make the distros that use your
> stuff compile against the KOffice tree.  Last option is that you can ship
> the koffice headers of the previous release in your plugins-tarball.
And how do you suggest to link ? Most distributions put the .so in the 
developement package, no development package, no .so, no link.

I really hope that you folk at the Berlin week-end will come up with a better 
decision.

-- 
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]