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

[Richard Dale]

On Wednesday 14 April 2004 07:42, Dominique Devriese wrote:
> Richard Dale writes:
> >> Note that I'm not commenting on the benefits of a separate release
> >> in general.  Personally, I'd like to see it happen, because of the
> >> interest it may create.  I'm wondering about whether this doesn't
> >> need to be discussed on kde-core-devel as well ?
> >
> > 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.

> > 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.

Alex and myself were being given contradictory advice about whether or not we 
should be working on ruby in a branch - as opposed to in the HEAD but not 
built be default. 

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.

> > 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.