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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
