On Tuesday 11 November 2003 12:20, Stephan Kulow wrote:
> On Tuesday 11 November 2003 12:42, Richard Dale wrote:
> > > Starting with next monday (17.11) the extra rule applies:
> > > * Every commit to released modules beside kde-i18n have
> > >   to contain a bug number with severity >= major. I'm trying
> > >   to watch the activities around bugs.kde.org as close as I can,
> > >   so make reasonable use of the severities.
> >
> > Does this apply to the kdebindings module too? In the past I've
> > regenerated the java bindings about a week or so before the final
> > release. If I do it too early, it only needs one minor change in one
> > kdelibs header to break the build, and the kdebindings list gets bug
> > report mails. As far as I know there are no translation or artwork
> > dependencies affecting the current JNI based java bindings.
>
> define minor change. I can't think of many reasons we'd need to change
> kdelibs interfaces for bug fixes. So I'd suggest you update the bindings on
> saturday and then do a check before the release. I hope it will result in
> no change. If it does not, you can of course still commit. That commit I'd
> define part of whatever commit gone into kdelibs to change the interface.
Yes, ok that sounds fine to me, I'll do that then. I don't get the impression 
that the headers are changing much for this release. As far as I can remember 
the last time there were changes being made to the KAction api and so on at a 
late stage. In the future I would like to have everything autogenerated as 
part of the configure, and not check any autogenerated stuff into the cvs.

> > I've been working on ruby bindings for a while, but I couldn't put them
> > in the KDE 3.2 release schedule, because it was too uncertain when they
> > would be finished and whether I'd be able to get them working with the
> > kdelibs classes at all. But now I really think the QtRuby bindings are
> > getting to the stage where they 'just work', and I'd like to add the
> > extension that allows you to do ruby programming under
> > 'kdebindings/kderuby' soon. Then tell people about them via an
> > announcement on dot kde news. Is it possible to call the ruby RAD stuff a
> > 'technology preview' for the 3.2 release, and only build it if specially
> > enabled with a configure option? Then perhaps add them properly on the
> > schedule for the 3.2.1 release with a full description, and more code
> > samples, documentation and fixes after the preview version.
>
> 3.2.1 is not supposed to contain new features, I don't see why you can't
> release the ruby bindings independent of KDE 3.2.x - they are just not
> there yet.
The KDE bit isn't in the cvs - but it does exist, so I could check it into a 
branch (eg KDERUBY_1_0) rather than the HEAD, and announce something. The 
sort of 'early adopters' who might try it out will be able to get it from the 
cvs ok I should think. I think kdebindings are more to do with developers and 
should be part of any KDevelop release, if there is such a thing. They're 
only needed in the main release if someone writes a kde app in ruby or java 
or whatever that they would like included in the release.

But my point is I wouldn't check it into the cvs unless I thought it had got 
to the stage of 'just working'. 95% of the code and functionality is in the 
QtRuby bit, not the kde-specific extension. I could have just added it to the 
release schedule when I only thought I had a 50% chance of getting it 
working. But I much rather under promise, over-deliver and look a slight 
prat, than the other way round and look a complete prat..

-- Richard