Re: Proposed Modules, My Take

[Maciej Katafiasz <ml mathrick org>]

Dnia 19-01-2005, śro o godzinie 19:12 -0700, Elijah Newren napisał:
> On Wed, 19 Jan 2005 22:59:50 +0000, Mike Hearn <mike navi cx> wrote:
> > On Wed, 19 Jan 2005 21:45:52 +0100, Murray Cumming wrote:
> > > For certain values of "break". The application continues to work if the
> > > application specifies a certain version of python, as it should. I wish
> > > that python did not allow applications not to specify a version, but
> > > it's not the first development environment to make it easy for people to
> > > make mistakes. I think that Java needs the same attention.
> > 
> > You're using a pretty much unique definition of stability there: to most
> > developers stability implies that it'll be OK to link old programs
> > against future releases, for the foreseeable future. So GTK+ is stable.
> 
> By your definition, no it is not.  Apps linked against GTK+-1.x cannot
> be linked against GTK+-2.x and expect to work.

That's to be expected because GTK+-2.x is 1) not 'forseeable future' for
gtk+-1.2 app 2) hardly a 'future release of gtk+-1.2'

> Similarly for GTK+2.x apps and GTK+-3.x whenever it is created.  GTK
> +-1.x is stable, and GTK+-2.x is stable, and GTK+3.x will likely be
> stable whenever it is ever created.  The reason that's good enough is
> that GTK+-1.x and GTK+-2.x can be installed at the same time on a
> machine and an app can use whichever one it wants.  This is a shade of
> stability that is good enough in this circumstance.  What Murray is
> talking about is the exact same thing for the bindings--it has a
> slightly different timescale perhaps, but different shades of
> stability for different problems.

The difference here is that Python, despite appearing to do so, doesn't
ever release minor releases, ie. ones where you can say "app compiled
against newer version might not work with older, but app compiled
against older version will certainly work with newer one". Python
releases can break both backward- and forward- compatibilty. So
essentially, in terms of GNOME lingo, Python never does minor releases,
every release is major one, despite first number in version (2.x) not
changing. Yes, it is confusing, yes, it is undesirable, but it happens
and the only way to shield against it is to do what we've always done --
reference soname of desired version (in this case, !# string). Although
it's app in position to do that, not GNOME platform as Sean suggests,
because referencing it in GNOME would really only change the place
breakage occurs, not remove it.

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>