[Kde-bindings] Release at the end of the month

[Dominique Devriese]

Richard Dale writes:

>> > I don't think we need a seperate bindings release. But the
>> > current KDE release rules seem to mean that if you can't get
>> > something ready for the initial KDE xx.0 release, then you can't
>> > add it subsequently. This isn't intentional,
>>
>> I think this is very intentional.  New features also means new bugs
>> and new translatable strings, two things that should be avoided in
>> a release freeze.
> I don't think being able to program kde apps in ruby or python is a
> 'feature', and as far as I know nobody does any string translations
> of kdebindings. I'm not sure if there are any strings - they would
> be in the ruby apps that you write with the bindings.

Yeah, I know, but I was talking about the policy in general, I thought
you were also.  See below for the kdebindings-specific stuff.

>> > but bindings aren't like kdelibs or kde apps and it isn't
>> > possible to follow the same release rules easily at
>> > all. Eg. PyKDE isn't ready for the KDE 3.2 release yet.
>>
>> Other modules have the same problem as well.  E.g. kdepim is doing
>> some of their own releases as well.

> Well, I don't think thats the same problem. With bindings the kde
> headers aren't frozen until fairly near the release. If you try and
> generate bindings against the beta headers, all that happens is you
> get bug reports about your bindings not building any more because
> someone made some minor change to a kdelibs header. So you can only
> really get started once the other guys have finished. But now all
> the bindings I work on are completely autogenerated it doesn't
> matter anymore.

Oh, right, I see.  You are of course very right.

> I think you were supposed to add everything you intended to put in
> the KDE 3.2 feature plan at the end of August or so last year. I
> hadn't even worked out how to get the Smoke library working with KDE
> then. Fortunately Alex managed to get it promoted to the HEAD branch
> in time to be tagged for the release, and it's all worked out fine.

Yes, kdebindings should adopt a separate release schedule ?  But well,
the downside of that is that someone is going to have to do the work
to actually package it up.  Then kdebindings could be exempted from
the normal commit rules.

>> > But I think the idea of announcing everything all at once is
>> > really good - there will be more impact. What we really need to
>> > do is put kdebindings on the map, and stop people thinking of it
>> > as some sort of 'interesting prototype' stuff.
>>
>> Yes, indeed we now have the problem that kdebindings is in a more
>> or less stable state with a lot of new stuff, but it is still a few
>> months until the next KDE release.  So, yes, a separate release
>> could be warranted...
> I'm not sure why we can't add stuff like PyKDE for KDE 3.2.3, if we
> don't need string translations etc - I'm not sure what the
> dependencies are.

Well, PyKDE is also a bit special, because it has already been tested
thoroughly outside KDE CVS.  Normally, HEAD is where an application or
lib matures first, and then gets promoted into a release.

cheers
domi