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

[Dominique Devriese]

Richard Dale writes:

> and now Marco has the juic tool working

Note that it was already working, just not on my test .ui files.

> it will really make a difference too (especially if juic is
> integrated with KDevelop). 

indeed.

>> The latest commits were mostly bugfixes, and most of them have been
>> backported to KDE_3_2_BRANCH.  So I don't think there would be any
>> special benefit from a separate release to the *java stuff.
>>
>> 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.

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

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

cheers
domi