Repost. This one applies cleanly over 275 and 276, posted earlier.
ChangeLog| 11 +++
NEWS |9 +-
doc/libtool.texi | 176 +--
libltdl/ltdl.c | 84 +-
libltdl/ltdl.h | 10 +--
5 files ch
On Mon, 19 Sep 2005, Gary V. Vaughan wrote:
Oops. I did not know that, I never used 1.4 in practice. :-/
I retract that then partly, I did not know 1.5 had regressions over 1.4.
I never meant to "sell" regression fixes as new features.
Bob, that's really not fair! The reason 1.4 didn't do e
Hi Bob, Ralf,
Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Sun, Sep 18, 2005 at 07:49:38PM CEST:
>>On Sun, 18 Sep 2005, Ralf Wildenhues wrote:
Development libtool offers few user-visible features where a new
feature is defined by new functionality. Most new "features" are
inter
Repost. Easing back on the lt_ptr removal.
ChangeLog|6 ++
NEWS | 13 +
doc/libtool.texi | 28
libltdl/ltdl.c | 26 --
libltdl/ltdl.h | 37 +
5 files chang
Hi Bob,
* Bob Friesenhahn wrote on Sun, Sep 18, 2005 at 11:05:33PM CEST:
> On Sun, 18 Sep 2005, Ralf Wildenhues wrote:
> >
> >1) D'oh. Makefile.in depends on aclocal.m4 through am__configure_deps.
> >So fix the install order to reflect that. At least I did get that right
> >in branch-1-5. It's
On Sun, 18 Sep 2005, Ralf Wildenhues wrote:
Two small issues:
1) D'oh. Makefile.in depends on aclocal.m4 through am__configure_deps.
So fix the install order to reflect that. At least I did get that right
in branch-1-5. It's actually difficult to find this experimentally on
modern hardware -
Two small issues:
1) D'oh. Makefile.in depends on aclocal.m4 through am__configure_deps.
So fix the install order to reflect that. At least I did get that right
in branch-1-5. It's actually difficult to find this experimentally on
modern hardware -- make install regularly completes these in les
Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf,
Thanks for reviewing.
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:52:06AM CEST:
>
>>Ralf Wildenhues wrote:
>>
>>>* Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:05:48PM CEST:
>>>
>>>I don't understand why now you start to rename _all_ of
Hallo Ralf,
Ralf Wildenhues wrote:
>>* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:52:06AM CEST:
>>
>>>Only the same arguments we both put forth for changing the name of
>>>lt_dlcaller_register -- forced to change function footprint to avoid
>>>problems with other clients' modules, which in t
Repost with changes in light of comments in this thread.
ChangeLog | 11 +++
Makefile.am |2 -
doc/libtool.texi | 47 --
libltdl/libltdl/lt__private.h | 10 +++
libltdl/ltdl.c| 5
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:52:06AM CEST:
> >
> > Only the same arguments we both put forth for changing the name of
> > lt_dlcaller_register -- forced to change function footprint to avoid
> > problems with other clients' modules, which in turn suggests a good
> > reason
Hi Bob,
* Bob Friesenhahn wrote on Sun, Sep 18, 2005 at 07:49:38PM CEST:
> On Sun, 18 Sep 2005, Ralf Wildenhues wrote:
> >>
> >>Development libtool offers few user-visible features where a new
> >>feature is defined by new functionality. Most new "features" are
> >>internal design changes.
> >-
Hi Gary,
* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:52:06AM CEST:
> Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:05:48PM CEST:
> >>* libltdl/ltdl.c (lt_dlcaller_register, lt_dlcaller_set_data)
> >>(lt_dlcaller_get_data): Renamed to avoid problems wi
Hi Bob,
Bob Friesenhahn wrote:
> On Sun, 18 Sep 2005, Gary V. Vaughan wrote:
>> I mean to soy that it is easier to resist the temptation to push another
>> patch into the tree when a future release date is looming. Having a 'can
>
> Does this mean that you are willing to back off on your latest l
On Sun, 18 Sep 2005, Ralf Wildenhues wrote:
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
hundre
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 on
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 defin
On Sun, 18 Sep 2005, Gary V. Vaughan wrote:
Ooh! Ouch! :-)
I mean to soy that it is easier to resist the temptation to push another
patch into the tree when a future release date is looming. Having a 'can
Does this mean that you are willing to back off on your latest large
patch?
Large p
On Sun, 18 Sep 2005, Ralf Wildenhues wrote:
We can always choose to stick with a troublesome stable branch for
longer if it turns out to need more work to iron out any bugs and
regressions rather than ploughing on with another head release...
thoughts?
Yes, just one: this is INSANE.
Seconded.
Hi Gary,
Gary V. Vaughan writes:
[dropping Chuck from Cc: list, as he surely reads the list and likely
doesn't want a copy of all of this in his INBOX too...]
Whooops. Sorry for overlooking that. Hope he has dupes turned off..
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Sun, Sep
Gary V. Vaughan wrote:
Peter O'Gorman wrote:
Gary V. Vaughan wrote:
|>>We can always choose to stick with a troublesome stable branch for
|>>longer if it turns out to need more work to iron out any bugs and
|>>regressions rather than ploughing on with another head release...
|>>thoughts?
|>
|>
Hi Peter,
Peter O'Gorman wrote:
> The thing is that I agree with Ralf here, releases should be made when
> necessary on the stable branch, and when features are complete and
> tested on HEAD.
I agree with both of you! In addition to that, I'm also extremely keen
to get an idea of how often we'd
Hi Ralf,
[dropping Chuck from Cc: list, as he surely reads the list and likely
doesn't want a copy of all of this in his INBOX too...]
Ralf Wildenhues wrote:
> Hi Gary,
>
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 01:38:30PM CEST:
>
>>Ralf Wildenhues wrote:
>>
>>>Gary, haven't you burnt
Hi Peter,
Peter O'Gorman wrote:
> Gary V. Vaughan wrote:
> |>>We can always choose to stick with a troublesome stable branch for
> |>>longer if it turns out to need more work to iron out any bugs and
> |>>regressions rather than ploughing on with another head release...
> |>>thoughts?
> |>
> |>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary V. Vaughan wrote:
|>>We can always choose to stick with a troublesome stable branch for
|>>longer if it turns out to need more work to iron out any bugs and
|>>regressions rather than ploughing on with another head release...
|>>thoughts?
|>
|>
|
Hi Gary,
* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 01:38:30PM CEST:
> Ralf Wildenhues wrote:
> >
> > Gary, haven't you burnt yourself enough with promising releases at
> > certain times?
>
> This is because we are locked in a feature based release policy. I
> think moving to a time based
D'oh, stupid typo in the last post. Here is the correct patch:
ChangeLog| 11 +++
NEWS |9 +-
doc/libtool.texi | 176 +--
libltdl/ltdl.c | 88 ++-
libltdl/ltdl.h | 10 +--
5 files chang
Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf,
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:30:32AM CEST:
>
>>I propose that we move from a feature driven release policy to a time
>>based one. After 2.0, we should aim for a stable release (say) every
>>3 months, with a feature freeze in
Hi Gary,
* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:30:32AM CEST:
>
> I propose that we move from a feature driven release policy to a time
> based one. After 2.0, we should aim for a stable release (say) every
> 3 months, with a feature freeze in the last six weeks. To maintain
> forwa
Ralf Wildenhues wrote:
> Hi Gary,
Hallo Ralf!
> * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 12:31:56AM CEST:
>
>>Okay to apply?
>>
>>Since we are explicity no longer supporting applications that don't
>>update to the new API with libtool-2.0, I've removed the deprecated
>>functions.
>
> I h
Hallo Ralf,
Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:05:48PM CEST:
>> * libltdl/ltdl.c (lt_dlcaller_register, lt_dlcaller_set_data)
>> (lt_dlcaller_get_data): Renamed to avoid problems with module
>> visibilty when linked with programs written for
Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:35:32PM CEST:
>>Charles Wilson wrote:
>>
>>>Huh? Right now (on cygwin) the shared library built by 1.5.x libtool is
>>>"cygltdl-3.dll" (e.g. current - age == 3).
>>>
>>>Somebody somewhere already bumped the c:r:a numbers
Hi Gary,
* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 12:31:56AM CEST:
> Okay to apply?
>
> Since we are explicity no longer supporting applications that don't
> update to the new API with libtool-2.0, I've removed the deprecated
> functions.
I have not seen a decision to that extent. Only t
Hi Gary,
* Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:05:48PM CEST:
>
> Okay to commit?
>
> * libltdl/ltdl.c (lt_dlcaller_register, lt_dlcaller_set_data)
> (lt_dlcaller_get_data): Renamed to avoid problems with module
> visibilty when linked with programs written for the
* Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:35:32PM CEST:
> Charles Wilson wrote:
> >
> > Huh? Right now (on cygwin) the shared library built by 1.5.x libtool is
> > "cygltdl-3.dll" (e.g. current - age == 3).
> >
> > Somebody somewhere already bumped the c:r:a numbers in HEAD because
> >
35 matches
Mail list logo
