From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10303181601.AA14391@clio.rice.edu>
Subject: Re: DJGPP 2.04 release? [Was: Re: nmalloc revisited]
To: djgpp-workers AT delorie DOT com
Date: Tue, 18 Mar 2003 10:01:48 -0600 (CST)
In-Reply-To: <3E76F02F.92F4A8DC@phekda.freeserve.co.uk> from "Richard Dawe" at Mar 18, 2003 10:08:47 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> I asked about starting the DJGPP 2.04 release cycle on 1st February (Thread:
> "Time for a 2.04 alpha release on Simtel.NET?").

Okay - my opinions ...

> Outstanding patches that should go in before an alpha (IMHO):
> 
> * fchdir
> * isnan
> * strto* & Inf, NaN
> 
> You could argue that fchdir should go in after, but it's a pretty major change
> in open/fopen, so lots of testing would be good.

I have no objections to these, but they seem less critical than other things.

> Fixes that could go in mid-cycle:
> 
> * fstat fix (_invent_inode on filename from fd_props)
> * stat fix (for directories on Win2k/XP)

What is this?

> Need to check:
> 
> * docs have been done for programs missing them;
> * other items listed on 2.04 page.
> 
> Push into 2.05:
> 
> * DXE

If we push this out, we will need to package it as a separate program
and REQUIRE it in the near future.  Or release 2.05 as soon as it's available,
forget the testing.  I think this is a bad idea.

Alternatives would be:
 1) blow off DXE, replace with DXE3 (not backward compatible) - add 6Kb
    to each executable startup.
 2) Check in current DXE3 code, have separate DXEgen and DXE3gen executables,
    not use DXE3gen yet, make everyone using DXE3gen change syntax sometime
    in future.
    
How about considering making all djdev executables link to a dynamic libc,
and having libc have it's own version/releases?

> * C99 compliance - restrict, math, complex numbers, etc.
> * New POSIX compliance
> * nmalloc (if we do this, Charles says: "someone needs to fix the current libc
> free() to early out if there are lots of items in the free list")

free is still "broken" and I don't think anyone has looked at it.

> I'm starting to think that it's better to get 2.04 soon than put yet more
> features in it. The bug fixes and features in it justify a release soon IMHO.
> We can always do a "short" release cycle for 2.05 (haha) - say a year to a
> year and a half.

If we put 2.04 out too soon, I'm thinking more like a 3-6 month refresh
would be required.