Creation of kdevplatform module

Matt Rogers mattr at
Thu May 3 05:44:37 CEST 2007

On May 2, 2007, at 9:40 PM, Allen Winter wrote:

> On Wednesday 02 May 2007 10:26:14 pm Alexander Neundorf wrote:
>> On Wednesday 02 May 2007 11:33, Matt Rogers wrote:
>>> On May 2, 2007, at 8:05 AM, Allen Winter wrote:
>> ...
>>>> IF we were to do this.. then
>>>> + The new module should be in place by 8 May.
>>>> + The libs code should follow typical kdelibs coding policies and
>>>> licensing
>>>>    requirements by the first beta release (25 June).  And kdevelop
>>>> and quanta
>>>>     should be using it.
>>> Is following kdelibs coding policies a requirement? KDevelop has its
>>> own coding style. Why can't we just follow that? What happens if it
>>> won't be ready for KDE 4.0 (which it won't be)?
>> IMO kdevelop is a project with releases independent from KDE (as  
>> koffice) and
>> as such can have its own policies, in coding style, release  
>> management and
>> others.
> Sorry, I wasn't clear.
> I'm talking about the policies dealing with a public API. i.e,  
> dpointers, inline
> methods, apidox, .. stuff like that.  I didn't mean coding style.    
> The licensing
> must be LGPL, BSD, or X11 (same as kdelibs).

Ah, ok. That does make sense and is acceptable.

> And i still think kdedevlibs would be a more appropriate module name.
> Or maybe kdesdklibs.

We prefer kdevplatform because it continues with the KDevelop name.  
It is also the name chosen by the various developers of this API, and  
there was quite a ruckus around the name the last time we tried to  
change it. I'd prefer not to have to go through that again.

> Release management of this new module should be put under the KDE  
> umbrella.
> Else, why did you post this request to the release-team ML?

We intend for this module to be release managed under the KDE  
umbrella once it is ready to go with a KDE release. We don't feel it  
(along with the rest of KDevelop or Quanta) will be ready in time for  
KDE 4.0, but when it is ready, we'd like to do an independent  
release, as well as have a release bundled with KDE 4.1. Of course,  
the exact schedule will depend on how far away KDE 4.1 is from our  
would-be separate release, but IMHO, that can be handled later.

This is the reason for emailing release-team.

More information about the release-team mailing list