RE: RFC version issues

[Murray Cumming Comneon com]

> other bindings can require upgrades of everything just to get 
> bug fixes for themselves if they wish, we haven't and aren't 
> going to do that. we're not putting the burden on users, the 
> easier we make things the better our bindings will be and the 
> more they will be used.

Users don't care about install libraries. They install applications.
Developers are usually happy to install updated dependencies when installing
their updated versions of their favourite development library.

> binaries are one of many ways people will install gtk2-perl. 
> CPAN is another (and most likely the primary method) and your 
> suggested version scheme wouldn't allow us to be on CPAN at 
> all.

So CPAN actually does a configure when you install? Then I guess that people
are used to these problems.

So, if CPAN does not allow you to do major API versioning then I guess
there's no way around this.

I'll leave you to it now. Thanks for explaining things to me.

> besides are we are completely modular, are we supposed to 
> match version numbers for each module? gtk+ doesn't match 
> gnome, pango doesn't match anything else.

The actual version number has nothing to do with this. But it's always clear
what minimum major version of the dependencies are needed, because the
configure scripts check for them.

> if i run gtkmm 2.0.x with gtk+ 2.4 (as you say is supported) 
> what does get_version_info return to me?

There is no need to discover a version of gtkmm at runtime. Version checks
are done at configure-time, and by the compiler if you don't get your
configure-time checks right. But I guess perl applications don't check their
use of an API until runtime.

I hope you find a solution - it sounds like a generic perl problem so
hopefully there is a generic solution.

Murray Cumming
www.murrayc.com
murrayc usa net