Stuart Ballard wrote:
On the other hand, well spotted (I think?) that 0.9.x might be
considered a lower version that 0.21 by packaging tools. dpkg
--compare-versions appears to think so, if I'm understanding how
tg use it right. This may be moot though as the debian classpath
package already
Hi Raif,
On Wed, 2006-03-01 at 05:51 +1100, Raif S. Naffah wrote:
what is the expected milestone (definition and how to measure it) to
reach before releasing a version 1 --or 1.4 whatever that final number
will be?
According to our homepage it is: GNU Classpath 1.0 will be fully
compatible
hello Mark,
On Wednesday 01 March 2006 22:23, Mark Wielaard wrote:
On Wed, 2006-03-01 at 05:51 +1100, Raif S. Naffah wrote:
what is the expected milestone (definition and how to measure it)
to reach before releasing a version 1 --or 1.4 whatever that final
number will be?
According to
a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and make the
next version number classpath-6.3 for the March 2006 release.
In either case we will just use a code name for a release that has
some special
theUser BL wrote:
I think the best wold be, if GNU Classpath 1.0 is 100% compatible to
Java 1.4 and GNU Classpath 2.0 would be 100% compatible to Java 1.5.
Why not take a lesson from Sun:
Classpath 1.0 implements JDK 1.1
Classpath 2.0 implements Java 2 aka JDK 1.2
Classpath 3.0 implements JDK
On Mon, 2006-02-27 at 23:09 +0100, Mark Wielaard wrote:
Hi Andrew,
On Mon, 2006-02-27 at 21:42 +, Andrew John Hughes wrote:
On Mon, 2006-02-27 at 17:54 +0100, Mark Wielaard wrote:
- Remerge CVS trunk with the generics branch
(I don't know whether Andrew has had time for that
Hi there,
I had a look at the mauve regressions. Here are my comments so far:
-PASS: gnu.testlet.javax.swing.JLabel.Icon (number 6)
-PASS: gnu.testlet.javax.swing.JLabel.Icon (number 7)
+FAIL: gnu.testlet.javax.swing.JLabel.Icon (number 6)
+FAIL: gnu.testlet.javax.swing.JLabel.Icon (number
On 2/27/06, Brian Jones [EMAIL PROTECTED] wrote:
Suggest making next release 0.90 and incrementing towards 1.0. The 1.0
release should be 1.4.0 (or 1.40 if you were going to be consistent, but
I digress). Anyway my $0.02.
0.90 has problems if there turn out to be more than 9 more releases
hello all,
what is the expected milestone (definition and how to measure it) to
reach before releasing a version 1 --or 1.4 whatever that final number
will be?
cheers;
rsn
pgpedKocpYsKX.pgp
Description: PGP signature
. And it is really hard to define
when
we hit 1.0. So the proposal is to keep using a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and
make the
next version number classpath-6.3
Stuart Ballard wrote:
On 2/27/06, Brian Jones [EMAIL PROTECTED] wrote:
Suggest making next release 0.90 and incrementing towards 1.0. The 1.0
release should be 1.4.0 (or 1.40 if you were going to be consistent, but
I digress). Anyway my $0.02.
0.90 has problems if there turn out
On Tue, 2006-02-28 at 17:45 +0100, Roman Kennke wrote:
-PASS: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest: valid
output (number 7)
+FAIL: gnu.testlet.javax.swing.text.MaskFormatter.MaskFormatterTest:
uncaught exception at valid output number 2:
I think the actual precedent is to go 0.9xx... as needed until you
_can_ declare the 1.0. So it's more of a mindset thing to bump the
number and get folks really working towards that 1 goal. You do not
need to feel limited to only 9 releases. There can in fact remain an
infinite number of
reached over the years. And it is really hard to define when
we hit 1.0. So the proposal is to keep using a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and make the
next version number classpath-6.3
is to keep using a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and make the
next version number classpath-6.3 for the March 2006 release.
In either case we will just use a code name for a release
. and make the next release-number
classpath-21, or adopt a year.month style version number and make the
next version number classpath-6.3 for the March 2006 release.
In either case we will just use a code name for a release that has
some special feature set that we are proud of, but we
to define when
we hit 1.0. So the proposal is to keep using a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and make the
next version number classpath-6.3 for the March 2006 release.
In either case
Hi Mark,
As some people have been saying already there were some impressive
showcases at Fosdem of things that just work now. So I feel it is time
to do a new snapshot this week to share all this great work with our
users. Both awt and swing made some very nice improvements, we have all
the
is to keep using a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and make the
next version number classpath-6.3 for the March 2006 release.
In either case we will just use a code name
is to keep using a sequence version
number. Either just drop the 0. and make the next release-number
classpath-21, or adopt a year.month style version number and
make the
next version number classpath-6.3 for the March 2006 release.
In either case we will just use a code name
On Mon, Feb 27, 2006 at 08:36:37PM +, Chris Burdess wrote:
Changes in version number format, etc. have a cost in that can
confuse (or at least complicate) packaging and versioning software
like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users).
If all we want is a sequence
discussion about this during Fosdem.
Everybody seems to agree 0.x really doesn't do justice to the maturity
we have reached over the years. And it is really hard to define when
we hit 1.0. So the proposal is to keep using a sequence version
number. Either just drop the 0. and make the next
Hi Andrew,
On Mon, 2006-02-27 at 21:42 +, Andrew John Hughes wrote:
On Mon, 2006-02-27 at 17:54 +0100, Mark Wielaard wrote:
- Remerge CVS trunk with the generics branch
(I don't know whether Andrew has had time for that since his Math
work. Please yell and scream if you need help
Hi Mark,
It then just needs to be brought up to date with the patches inbetween
Saturday and the point where the release is called.
Roman wanted some more time to stabilize so lets just pick Saturday as
the day we freeze (meaning, when the release branch is created). Then
only patches
to 1.5, we should call ourselves 1.5.x and so forth.
This makes the situation much more clear to casual users as to what
they can expect in terms of features.
Full ACK. This really makes sense.
Cheers,
Michael
Suggest making next release 0.90 and incrementing towards 1.0. The 1.0
Mark Wielaard wrote:
On Wed, 2004-03-31 at 10:32, Jeroen Frijters wrote:
I'm planning my first real IKVM release (to be included
with the Mono
1.0 release) and I'd like to know when the next GNU
Classpath release is
approximately due. Do you know have a date planned already?
I like
Hi,
On Wed, 2004-03-31 at 10:32, Jeroen Frijters wrote:
I'm planning my first real IKVM release (to be included with the Mono
1.0 release) and I'd like to know when the next GNU Classpath release is
approximately due. Do you know have a date planned already?
I like our time-based release
Hi Mark,
I'm planning my first real IKVM release (to be included with the Mono
1.0 release) and I'd like to know when the next GNU Classpath release is
approximately due. Do you know have a date planned already?
Regards,
Jeroen
___
Classpath mailing
Bryce McKinlay wrote:
I think that is not a bug, but rather an obscure C++ misfeature called
trigraphs.
Don't I recall reading in the index of some GNU manual (probably for
gcc):
ANSI Trigraphs
You don't want to know about this particular braindamage.
:)
Chris Gray
VM Architect,
Hi,
On Thu, 2002-02-07 at 10:18, Chris Gray wrote:
Bryce McKinlay wrote:
I think that is not a bug, but rather an obscure C++ misfeature called
trigraphs.
Don't I recall reading in the index of some GNU manual (probably for
gcc):
ANSI Trigraphs
You don't want to know about
Mark Wielaard wrote:
The patch is neccessary and does work for me (gcc 3.0.4 debian
prerelease). Does anybody know if it is a real fix or something bogus?
Isn't it just that :: is a valid operator in C++ (but not in C)?
I have no idea what a line of code that uses three : operators in a row
Mark Wielaard wrote:
Hi,
On Thu, 2002-02-07 at 10:18, Chris Gray wrote:
Don't I recall reading in the index of some GNU manual (probably for
gcc):
ANSI Trigraphs
You don't want to know about this particular braindamage.
:)
Really funny. The gcc manual actually says that
Mark Wielaard wrote:
- There seems to be a gcc compiler bug that makes the following
patch
necessary:
--- orp-1.0.9/base_natives/common_olv2/mon_enter_exit.cpp
+++ orp/base_natives/common_olv2/mon_enter_exit.cpp
@@ -294,7 +294,7 @@
#else
nop;nop;nop
Hi,
Here is my TODO list for the next (0.03) release.
It seems like a good idea to get a release out the door now that we have
the AWT and license clarification worked out and the libraries seem to
work with Orp 1.0.9 out of the box. 0.02 was released more then a year
ago and we made lots of
Hi,
On Sun, 2002-02-03 at 17:34, Brian Jones wrote:
Mark Wielaard [EMAIL PROTECTED] writes:
- Check and apply patches in Savannah bugdatabase
http://savannah.gnu.org/patch/index.php?group_id=85.
A lot of the patches that Intel submitted were set to postponed but
the copyright
Hi,
On Sun, 2002-02-03 at 18:25, Mark Wielaard wrote:
The one for gcc 3.1 (CVS) is:
--- vm/reference/java/lang/Class.java 22 Jan 2002 22:27:03 - 1.14
+++ vm/reference/java/lang/Class.java 3 Feb 2002 17:05:22 -
@@ -68,7 +68,7 @@
public class Class {
private Object[]
Mark Wielaard [EMAIL PROTECTED] writes:
The FSF has a signed document, but it failed to define developer
names, so RMS is not going to sign it until they get a letterhead
defining whose contributions count. So I set the patches to postponed
again.
Bummer. I might take a look to see
Mark Wielaard wrote:
- Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two
workaround for compiling with gcj in my local tree. It might be a good
idea to apply them.
I will try to fix any remaining issues preventing classpath being
compiled with GCC 3.1.
regards
Hi Bryce,
On Sun, 2002-02-03 at 21:27, Bryce McKinlay wrote:
Mark Wielaard wrote:
- Add workaround for compiling with gcj (3.0.x and 3.1 CVS). I have two
workaround for compiling with gcj in my local tree. It might be a good
idea to apply them.
I will try to fix any remaining
39 matches
Mail list logo
