Re: Proposed Modules, My Take

[Elijah Newren <newren gmail com>]

On Thu, 20 Jan 2005 11:12:10 +0100, Maciej Katafiasz <ml mathrick org> wrote:
> 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:

> > > 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'

This becomes really shaky ground.  Who defines 'forseeable future'? 
Without a solid definition, one can claim stability of their library
or programming language merely by having insufficient foresight.  One
could also easily argue for those that have applications with a longer
lifespan that the length of time between gtk+-1.2 and gtk+-2.x was
very tiny and thus gtk+-2.x would have been in the forseeable future.

> > 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

Point noted.  Perhaps this is part of what one would use in the
definition of 'foreseeable future'.  :-)

Cheers,
Elijah