[Top][All Lists]
[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