Re: release policy

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Sun, Sep 18, 2005 at 06:41:54PM CEST:
> On Sun, 18 Sep 2005, Gary V. Vaughan wrote:
> >
> >>You talked about 2.0 being close more than a year ago, it's not out.
> >
> >Agreed.  And the fault there was piling in more features without
> >stabilising the existing ones.
> 
> Development libtool offers few user-visible features where a new 
> feature is defined by new functionality.  Most new "features" are 
> internal design changes.

I disagree strongly:

- no stupid C++/Fortran 77 checks for C-only users (plus several
  hundred KB smaller configure scripts)
- better support for linker inherited flags (-pthread etc)
- better support for necessary compiler flags in CFLAGS
  (the dlsym file is actually compiled with them)
- basic support for Fortran 90/95
- somewhat better support for mingw/cygwin, AIX
- ltdl may be used without autotools
- (hopefully soon) msvc support

These are all not internal design features.  I know several packages
that _badly_ need some of these features.  Just the first feature is
enough of a bugger to users that it would have justified a new stable
release, IMNSHO.

Surely there are other changes as well.  The internal tree organization
has caused a lot bugs, surely, and in hindsight that has probably been
a bad idea, at least at that time.  But it has also uncovered some bugs
present before in libtool.

> >Nor mine.  And I agree that much work needs to be done in stabilising
> >before we add any new features.  During that time (and beyond if we
> 
> To me "stable" means that there are very few changes needed.  It 
> represents a point of equilibrium.  Rather than everyone needing to 
> run to the other side of the raft, it should only be necessary for 
> there to be a minor change in seating position to avoid capsizing.  We 
> should be at that point after several years of development.

I must admit that you speak in riddles to me -- I have not understood
this paragraph completely.

If you mean that libtool should not _need_ any largish changes, since
it's been developed for a long time already:  That would be nice.
But reality is different at times.  May I remind you that it was you
that called for a different architecture more than once?  Where
libtool.m4 knowledge would not end up in each and every packages'
configure script?  Another example: special characters in object file
names.

Surely it would be nice if none of any desired new features would
require large changes.  But we have what we have at the moment, and I
do look at this in a very pragmatic way.

Cheers,
Ralf