Re: Next release, vacation, LinuxTag

On Sun, 23 Apr 2006 23:22:45 +0200 Mark Wielaard <[EMAIL PROTECTED]> wrote: > Hi, > > On Sun, 2006-04-23 at 13:07 +0200, Jeroen Frijters wrote: > > Mark Wielaard wrote: > > > I believe that with your and Andrew's work we are now synced > > > for the VM Classes between generics and trunk. > > >

Next release, vacation, LinuxTag

Hi, On Sun, 2006-04-23 at 13:07 +0200, Jeroen Frijters wrote: > Mark Wielaard wrote: > > I believe that with your and Andrew's work we are now synced > > for the VM Classes between generics and trunk. > > Yeah, I think so too. > > > It would be a good point to declare the vm classes interface >

Re: Next release

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

Re: milestone for release 1. was Next release

Raif S. Naffah swiftdsl.com.au> writes: > > 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 --o

Re: Next release

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

Re: milestone for release 1. was Next release

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

Re: milestone for release 1. was Next release

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 compatib

Re: Next release

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 alre

Re: Next release

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

Re: Next release

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: > > java.lang.N

Re: Next release

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 tu

Re: Next release

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

milestone for release 1. was Next release

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

Re: Next release

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 m

Re: Next release

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

Re: Next release

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

Re: Next release

When we are in the same situation with respect 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.9

Re: Next release

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 p

Re: Next release

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

Re: Next release

e 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 release-number > classpath-21, or adopt a year.month style versi

Re: Next release

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

Re: Next release

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

Re: Next release

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

Re: Next release

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 >

Re: Next release

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

Re: Next release

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

Re: Next release

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

Next release

tice 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 release-number classpath-21, or adopt a year.m

Testing the next release (builder make distcheck)

Hi, For those of you who want to help test the next (0.20) snapshot release builder.classpath.org now has a -pre dist tar ball available whenever make distcheck succeeds. See http://builder.classpath.org/ The autobuilder runs a couple of times a day so it should be fairly fresh. So it might also b

RE: Next release?

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

Re: Next release?

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 cy

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

Re: NEWS file for next release

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 act

Re: NEWS file for next release

Stuart Ballard wrote: >I have no idea what a line of code that uses three : operators in a row >could possibly mean (in either language) and I can't find the source >code file to get context. But my guess is that the tokenizer is seeing >:: and thinking "ooh, class member operator" (or whatever t

Re: NEWS file for next release

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

Re: NEWS file for next release

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 kn

Re: NEWS file for next release

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

Re: NEWS file for next release

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

Re: NEWS file for next release

Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > On Mon, 2002-02-04 at 13:50, Nic Ferrier wrote: > > Mark Wielaard <[EMAIL PROTECTED]> writes: > > > > > * Support for compiling in a separate directory, as an example you may > > > cd classpath-0.03; mkdir build; cd build; ../configure; mak

Re: NEWS file for next release

Hi, On Mon, 2002-02-04 at 13:50, Nic Ferrier wrote: > Mark Wielaard <[EMAIL PROTECTED]> writes: > > > * Support for compiling in a separate directory, as an example you may > > cd classpath-0.03; mkdir build; cd build; ../configure; make > > This didn't work for me on my recent build. But

Re: NEWS file for next release

Mark Wielaard <[EMAIL PROTECTED]> writes: > * Support for compiling in a separate directory, as an example you may > cd classpath-0.03; mkdir build; cd build; ../configure; make This didn't work for me on my recent build. > * Works with Orp 1.0.9 out of the box. Build instructions can be f

Re: TODO list for the next release

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 remain

Re: TODO list for the next release

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 Br

Re: TODO list for the next release

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 lo

Re: TODO list for the next release

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 Ob

Re: TODO list for the next release

Hi, On Sun, 2002-02-03 at 17:34, Brian Jones wrote: > Mark Wielaard <[EMAIL PROTECTED]> writes: > > > - Check and apply patches in Savannah bugdatabase > > . > > A lot of the patches that Intel submitted were set to postponed but > > the

Re: TODO list for the next release

Mark Wielaard <[EMAIL PROTECTED]> writes: > - Check and apply patches in Savannah bugdatabase > . > A lot of the patches that Intel submitted were set to postponed but > the copyright assignment papers have been sorted out so they can go

TODO list for the next release

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 prog