1.5 branching

[Jarosław Staniek]

David Faure wrote:

> On Sunday 05 March 2006 23:19, Boudewijn Rempt wrote:
>> On Sunday 05 March 2006 23:15, Robert Knight wrote:
>> > > Thank heavens there's atleast one person who is rational about KDE4
>> > > expectations!
>> >
>> > Is there a roadmap somewhere which shows where KDE4 is in terms of its
>> > development?  The only information I have found so far is a post to
>> > kde-core-devel which essentially said that there was still a lot of
>> > work to do in kdelibs and that the built-system is still in something
>> > of a flux.
>> >
>> 
>> The technical working group should be working on that.
> 
> The current plan is to stabilize kdelibs (at least the technology and the
> API) by October
> http://developer.kde.org/development-versions/kde-4.0-release-plan.html
> 
> Note that this won't happen all by itself; it would be very good if
> KOffice developers would have a look at what they're missing from kdelibs,
> and work on integrating that into kdelibs4; this is a unique opportunity,
> since after 4.0 is out, koffice will likely stick to "latest kdelibs
> release" as requirement, i.e. not possible anymore (or not so easy) to add
> stuff to kdelibs and use it in koffice. So I strongly encourage KOffice
> developers to take a look at kdelibs trunk - this is even more important
> than working on a 1.6 release, which I find to be a bad idea. We should
> instead of a TP1 of KOffice to provide alongside KDE-4.0-TP1...

FYI: I'd like to provoke further discussions as everybody can have different 
needs, plans regarding to kdelibs4.

Upward compatibility in KDElibs4?

Is kdelibs4 API going to be upward compatible? Sometimes. Personally I think I 
can only manage to _finish_ database layer(s) for kdelibs 4.1 and even then I 
am not sure the API is stable. I am not only porting the stuff to Qt4 but 
developing it constantly. 
I'd love to see only most important (and ready) new features in kdelibs 4.0 
and the rest (usually optional stuff) in 4.1. See how GHNS was introduced. 

What's better?
- to release often and claim the API is stable (there will be some things 
missing and waiting for KDE5), or
- (my favourite) to split new things to 4.0 and 4.1 parts (and probably with 
4.0-TP prototype) to make more devs happy?

For me eventually, in the pesimistic case, the db layer can stay at 
kofficelibs level.
 
Don't get me wrong - I'd like to deliver all planned APIs and features 
quickly, but it's more important to be realistic about this and to have an 
emergency plan.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

Sponsored by OpenOffice Polska to work on
* Kexi & KOffice: http://www.kexi-project.org | http://koffice.org/kexi
* KDE3 & KDE4 Libraries For Developing MS Windows Applications:
                   http://www.kdelibs.com/wiki
See also:
* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
* Kexi Support:        http://www.kexi-project.org/support.html