Re: Proposed Modules, My Take

[Mike Hearn <mike navi cx>]

On Thu, 20 Jan 2005 15:36:43 +0100, Murray Cumming wrote:
> I've developed a lot of software for Windows, and I've almost never been
> able to install it without installing extra development-platform stuff,
> spending weeks with InstallShield.

I'm not sure what you're referring to here, could you give some examples?
I've also written a lot of software for Windows and rarely had such
problems (though I did manage to avoid InstallShield).
 
> This has become slightly easier if you just target old stagnated APIs
> like MFC which have propagated everywhere now (though they did a new
> parallel-install version of that recently for MSVC++ 7, so it wouldn't
> be enough to have v7 if you wanted v6), but those are not the APIs
> developers use now anyway, because they are no longer getting important
> API additions.

Microsoft typically statically link language bindings (or apps are
expected to ship them as redistributables). That's OK for C++ or Visual
Basic because the runtimes are fairly small but not OK for Python which is
huge.

> SUN's definition of ABI stability is a great deal more complex, allowing
> for various types of guarantees, as we've heard recently.

I was thinking of Java rather than Solaris, but yes it's not a binary
on/off thing.

> I agree that such a platform would be good. I believe it means that
> distros must continue to ship old versions, and distros should be
> consistent. Then a phrase like "I have GNOME 2.10" would have some
> meaning across all distros. That's difficult. I really do believe that
> distros need to care about this.
> 
> I don't believe that stagnation (never ever doing new parallel-install
> versions) is the way to get there.

I think you're assuming that to improve an API you have to break the
interface then make it parallel installable. That's not right, you can
evolve and improve an API without doing that: see the new file chooser API
in GTK+ 2.6 for instance.

Anyway, the point isn't so much that APIs shouldn't change, clearly they
should, it's about how that change is managed and versioned. Right now at
first glance it looks like eg, GTKmm 2.4 is backwards compatible with 2.2
so if 2.2 is present, it'll all work. But it's not, and even if it was g++
isn't. Same for some of the other parts of the bindings release.

Whereas with GTK+ and GNOME, if the user has 2.6 you know (in theory) that
apps targetting 2.4 will work because the API is stable and therefore
older interfaces are guaranteed to be present, and the C ABI is
also stable.

thanks -mike