gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep-base code freeze


From: David Chisnall
Subject: Re: gnustep-base code freeze
Date: Thu, 24 Mar 2011 11:29:46 +0000

On 23 Mar 2011, at 17:56, Richard Frith-Macdonald wrote:

> Can we please spend the next few days testing base but not making any changes 
> other than documentation and any fixes for serious bugs (and perhaps the one 
> number formatter bug reported by the testsuite).
> I'd really like a new base release this month, and there's not much of it 
> left.

There are only two things I'd still like to do before the next release:

1) Check that all of the headers are safe for ObjC++ inclusion.  On OS X, you 
can just #import any of the Cocoa headers into ObjC++.  With GNUstep, you need 
to bracket the import with extern "C" { }, because we don't do this in headers. 
 Only headers that declare functions or globals need this done.

2) Add ivars when compiling with the non-fragile (not mixed) mode, rather than 
dangling off the pointer at the end.

Of these, the first one is the only one that's actually important.  The second 
can be done later, it's just a small performance improvement, so I'm happy to 
postpone it until after the release if there are any objections to doing it 
before.

> One thing I'd quite like to do, but am not entirely sure about ...
> 
> Can we take the current svn trunk code and copy it back to the stable branch 
> (with versioning revisions) so that we can make a 'stable' release which 
> contains all the new/recent functionality and the support for the latest 
> compilers and runtimes?   This would have to be binary compatible with the 
> existing stable base library (I've been trying not to introduce any 
> incompatibilities, but can other people check this).
> 
> The reason I'd like to do this is that having a new release of both the 
> stable and development branches might get the new features out to people via 
> different distributions more quickly.  Is this a good idea?

I thought at FOSDEM we decided not to do the stable/unstable thing?  
Distributions like Debian will only pick up the stable one, which means that we 
end up with loads of people complaining that feature X doesn't work with 
GNUstep, even though it's been supported for a year in trunk and six months in 
the latest release.  

And, from a Free Software perspective, I don't think we should put any special 
effort into maintaining a binary-compatible version, since the main benefactor 
will be people wishing to ship non-Free software.

David

-- Sent from my STANTEC-ZEBRA


reply via email to

[Prev in Thread] Current Thread [Next in Thread]