Daniel Reed <[EMAIL PROTECTED]> wrote:
> Several GNU projects (including GCC) do leave off .0's for anything past the
> minor number, so it seems ls -v can't be the final authority :/
It does not follow that this numbering scheme is a good one. I would
argue that it isn't. The gcc maintainers se
On 2003-09-29T22:50+0200, Alexandre Duret-Lutz wrote:
) planning to make 2.2 < 2.3a < 2.3. That would be counter
) intuitive. IMHO any numbering scheme ought to work with `ls -v'.
ls ls -v ls -rt
naim-0.11.5.1.tar.gz naim-0.11.5.1.tar.gz
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
[...]
Gary> And that's why people find our version scheme confusing. I'm not sure
Gary> how we ended up working in this way, I think we copied it from
Gary> Automake?
Tsk tsk tsk. Libtool used that scheme first. Automake copied it
On Monday, September 29, 2003, at 04:51 pm, Bob Friesenhahn wrote:
On Mon, 29 Sep 2003, Gary V. Vaughan wrote:
I think when we branch for a release (say the upcoming 1.6), version
numbers
in the branch should continue to be "1.6.?", but that
the trunk
should bump its minor number to make it cl
I'm trying to build php-4.3.3.
I did as for many other packages (libxml2, libxslt, libiconv, zlib, etc.)
but it seems there is something different here concerning the way it links the
application.
configure is ok, make is ok until link process. the command is:
#> libtool --silent --preserve-d
Gary V. Vaughan wrote:
I think when we branch for a release (say the upcoming 1.6), version
numbers in the branch should continue to be "1.6.?", but
that the trunk should bump its minor number to make it clear the trunk
is very different to the stable branch: "1.7?". We would of
course continu
On Mon, 29 Sep 2003, Gary V. Vaughan wrote:
> I think when we branch for a release (say the upcoming 1.6), version numbers
> in the branch should continue to be "1.6.?", but that the trunk
> should bump its minor number to make it clear the trunk is very different to
> the stable branch: "1.7?".
I am considering changing the version numbering scheme we use for alpha
releases of libtool, which are currently a source of much confusion. The
release rules in Makefile.am, and the release procedure documented in
README-alpha are all that will need updating.
I think when we branch for a rele
Tor Lillqvist wrote:
I have found that to ensure a mixture of Cygwin-based tools (for
instance shell scripts that run under a Cygwin shell, or Cygwin Perl
scripts) and native (mingw) tools interoperate reliably one needs to
make sure that the same paths are valid (and point to the same files)
in bo
[EMAIL PROTECTED] said:
> Sun has a lot of lawyers, and they've been pretty aggressive than most
> about staking their claims on the linguistic turf (so they can sell it
> off).
That's a rather twisted interpretation of Sun's use of trademarks, IMO.
Another way of interpreting this is that Sun is
On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote:
> Actually if it was branch-1-5 you were testing, that'd be the new 1.5.0a
> (1.5.1) release. 1.5b would be on HEAD (as far as I understand the
> esoteric version numbering upstream use) and a pre-release of
> libtool 1.6 (which
On Fri, 2003-09-26 at 20:46, Robert Millan wrote:
> The libtool upstream maintainers are preparing a new 1.5b release. On their
> behalf I've recently attempted to test a snapshot from CVS branch-1-5 on all
> architectures Debian supports (or pretends to support) that I had access to.
>
Actually
[ CCing to debian maintainer and libtool upstream ]
Hi there folks.
The libtool upstream maintainers are preparing a new 1.5b release. On their
behalf I've recently attempted to test a snapshot from CVS branch-1-5 on all
architectures Debian supports (or pretends to support) that I had access to
Stephen Crawley writes:
>
> [EMAIL PROTECTED] said:
> > Sun has a lot of lawyers, and they've been pretty aggressive than most
> > about staking their claims on the linguistic turf (so they can sell it
> > off).
>
> That's a rather twisted interpretation of Sun's use of trademarks, IMO.
>
14 matches
Mail list logo
