Re: package version macros, pango backspace_deletes_character

[Owen Taylor <otaylor redhat com>]

On Tue, 2004-02-03 at 16:40, Ross McFarland wrote:
> Owen Taylor said:
> > Let's go through the logic:
> >
> >  - If you actually care about application compatibility, you must have
> >    some concept of API versions. I must be able to say that my Perl
> >    program works with version 2.4.0 or newer of gtk2-perl.
> 
> $Gtk2::VERSION gives you what version of the bindings you're working with and
> it has to have a format similar to 1.023, a legal perl version number.

(You aren't using the more recent $PERL_VERSION v1.2.3 convention?)

> >  - Using the version of GTK+ you compiled against as the API version
> >    doesn't work because someone could always take an old version of
> >    your perl binding and compile it against GTK+-2.8.
> 
> exactly right, that's why to really know you look at both $Gtk2::VERSION
> (which tells you what could of been bound) and Gtk2->get_bound_verison_info
> (which tells you what Gtk2 was compiled against)

Sounds like a real source of confusion to me...

[...]

> whatever release we have on CPAN has to support older gtk+'s, not just the
> newest, or otherwise someone on a rh8/9 system can't install Gtk2 from CPAN.
> they'd have to upgrade gtk+ first, that's not something we want to require
> them to do. that's the kinda dependancies that make people give up when
> installing an app. getting Gtk2 off of CPAN is a two minute exersize, if you
> have to upgrade gtk+ first it becomes much more involved.

My experience is that people don't spend most of their time on the
stuff that goes right, they spend the time on debugging what goes
wrong.

Having the situation where you can have version 1.023 of Gtk2 and
version 2.4 of GTK+ but your program dies randomly in the middle
because it tries to call a GTK+-2.4 function and Gtk2 happened
to be compiled against GTK+-2.2 is just asking your mailing
lists to be filled with confused people. 

(Yes, I understand your scheme allows the version of GTK+ that
CPAN was compiled against to be checked explicitly, so you can
catch such problems at least at app startup. But I suspect authors
won't get that right. And it's certainly not representable by
common versioning schemes used by RPM, dpkg, etc...)

Unfortunately, upgrading your GTK+ on rh8/9 is *not* as easy as I'd
like; I'd really like to have standardized binary packages available
for common distributions. But on the other hand, I really doubt that
any GTK+ program written recently will work with the version of GTK+
on Red Hat 8. (2.0.9, IIRC)  

So you just create the situation where they install Gtk2, find it
doesn't actually run the program they want to run, upgrade their GTK+,
find the program still doesn't run, figure out how to force the 
CPAN downloader to reinstall a version it already has installed...

> i won't argue if you think this is a mess, i do, but given the situation in
> which we find ourselves it's the only way we've come up with to address all of
> the issues

I think my opinion about the right direction is clear from the above...
keep it simple, we're not *that* fast at releasing stable versions
of GTK+ with new API :-)

> reguardless this isn't an argument why there shouldn't be VERSION macros in
> pango, if they've got a purpose in glib/gtk+ why wouldn't they serve the same
> purpose in pango?

The version info macros were added to GTK+ long ago, either before or
shortly after version 1.0.

We saw awful messes when people tried to make language bindings compile
against multiple development versions of GTK+ 1.1. Code that was
more #ifdefs than code. Having seen many bad examples and few good
examples, I wasn't inspired to go through the hoops to create such
#defines for Pango.

In some sense it isn't my business to tell people what they can and
can't do with Pango, just to provide the capabilities. But it's not at
all impossible to tell what version of Pango you are compiling against.
It's just a little more work. And since I believe conditionalizing
against versions of Pango rather than just requiring one version
you need is essentially misguided, I don't want to make it easy. :-)

Regards,
						Owen