RE: gtk2-perl

[Murray Cumming Comneon com]

> we're currently in the 0.9x beta series for 1.00.  we're 
> following perl
> module versioning of x.yy, but we've been using even numbers for
> "public" releases and odd for cvs, until the beta series; 
> sourceforge's
> anon cvs was several days behind for a month or two, so we started
> releasing the beta series every week to get testers.

I don't understand. A release is a release and cvs is cvs. No release is not
really a release.
 
> the plan is to hit 1.00 in the next couple of weeks, and 
> freeze the API
> from that point; unfortunately, i imagine the number of 
> people using the
> bindings will balloon after 1.00, at which point we'll find 
> the bugs we
> couldn't find before for lack of testers... this means there will
> doubtless be a 1.20.
> any good advice on how to manage this sort of thing?

I don't see the point of freezing API that you know has not been tested
properly and which will be broken very soon. If you freeze an API then
people will expect you to support it.

In my opinion, marking something as "1.0" in order to make people use it is
an inappropriate use of version numbers. Tell people that it's pretty good
and that they should try it. Don't try to fool people into thinking that
it's API frozen. Lots of releases is a good way to get attention - it sounds
like you are doing that already.


> from what i can tell by changelogs, the defs files used to be generated
> by gtk+ itself, until sometime before 2.0.  what happened?

I didn't know about that. It's ancient history.

> wouldn't it
> make more sense for gtk+ to maintain the defs for consistency,
> especially now that the format is standardized?

Almost everybody uses h2defs.py from pygtk, so there is some consistency.
However we do tend to have our own little tweaks, and there hasn't been any
real benefit so far to unifying them. Feel free to push that if you think
it's important.

Murray Cumming
murrayc usa net
www.murrayc.com