RE: gnustep-base code freeze

[Nicola Pero]

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

Sounds great. :-)

But there's a few improvement to configure for gnustep-make and gnustep-base
(to improve detecting support for ObjC exceptions and blocks) which are
pending.

Shall I go ahead and make these changes in the next day or two, or shall we
make them after this release ?

I think they are good to have, but would require another few weeks
of widespread testing in the wild before we can release them.  If you
want to release quickly, it may be too late ?

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

Sure.  I guess you're worried about binary compatibility because you're thinking
of Linux distributions and such like.  In that case, though, it's good to 
backport
new features, but in terms of compiler/runtime support, keep in mind that
for example the libobjc contained in GCC changed from GCC 4.5 to 4.6 and had its
so name increased from 2 to 3.  That means a gnustep-base package shipped by a 
Linux
distribution is either built against libobjc.2 or against libobjc.3.  It can't
be linked against both.  So, once you upgrade the libobjc package to libobjc.3,
you'll also have to upgrade your gnustep-base package to one linked against 
libobjc.3,
at which point you may as well just install the latest gnustep-base package (all
the other packages on top will also be linked either against libobjc.2 or 
libobjc.3,
but can't be linked to both, so they'd all have to be upgraded too).

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

Probably.  I'm a bit confused by the terminology though.  The new release
from trunk would be a "stable" release presumably ?  So, it would be 1.22.0 ?

And you also want to backport changes to the old stable release, 1.20.x,
releasing 1.20.{x+1} ?

That makes some sense, even if there is the problem of testing 1.20.{x+1}, 
because
I think everyone as been testing from trunk, ie, they tested the future 1.22.0
(and when you backport things, typos/mistakes may slip in).

Or, are you saying that what is in trunk would simply become 1.20.{x+1} ?

Thanks