Re: gnustep-base code freeze

[Richard Frith-Macdonald]

On 24 Mar 2011, at 11:29, David Chisnall wrote:

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

Checking is always good (though ObjC++ support is not a release stopping issue 
since practically nobody uses it).

> On OS X, you can just #import any of the Cocoa headers into ObjC++.

This is/should-be true for gnustep-base too ... so if your checking shows 
problems here we should fix it.
I imagine there might well be problems with newer headers like the ObjC2 stuff 
though.

> With GNUstep, you need to bracket the import with extern "C" { }, because we 
> don't do this in headers.

Yes we do.

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

I'm not sure what you are wanting to do here(I though't I'd already added 
support for non-fragile builds), but it certainly doesn't sound like bugfixing, 
so we shouldn't be doing it now.

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

Yes... that's why I want the current development version to become 'stable' ... 
so they'll pick up current code.
Not sure what to do about the development/stable  distinction after the release 
though.


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

The main people asking for binary compatibility are packagers putting gnustep 
into distributions, who don't want to have to rebuild everything that uses the 
core libraries.