gnustep-dev
[Top][All Lists]
Advanced

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

Re: Next release


From: Fred Kiefer
Subject: Re: Next release
Date: Wed, 15 Apr 2009 08:52:57 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

What ever numbering system you prefer :-)
To me it is just the same and people will always find a reason to
complain about it.

For gui I would like to delay a new release for a few weeks. Gregory has
done a load of changes which will need some testing. And one set of them
(The changes for autoresize on NSView and subviews) surely is a work
around for some kind of problem. I am still trying to figure out from
the changes what the underlying problem might be. Most of the changes
have been reverted, but the remaining on on NSSplitView leads to an
inconsistency between objects loaded from a NIB file and ones created in
code. This is not what we want, but Greg surely had a good reason for
this change. If only he would tell us...


I am also currently looking into a problem with NIB loading, which might
even be related to Gregs issue. The NIB file for the SimpleWebKit
Browser gives different results for the autoresizes subviews ivar on
Cocoa and GNUstep. This code uses a binary NIB file
devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/MyDocument.nib/keyedobjects.nib

When converting this NIB file to XML (with a simple tool I have written
that just uses to calls on NSPropertyList) I end up with an entry

<key>NSvFlags</key>
<false/>

This looks completely wrong to me, but perhaps somebody with more
understanding of keyed coding could explain this?

After these two issues have been resolved a new release would be fine
from my point of view.

Fred

PS: I will be away for the next ten days, so don't expect something quick.

Adam Fedor wrote:
> It's been a long time now (LTN) since our last release, perhaps we
> should do a new one soon?   Also, in an effort to please everyone
> (ETPE), I was thinking we should separate the release numbering from the
> SO version numbering, at least on the unstable branch as long as there
> are no ABI changes.  This should be really easy as we just need to define
> 
> INTERFACE_VERSION
> 
> in the top-level makefile.  So
> 
> Base/Gui unstable release:
>   Subminor release (1.19.X) - bug fixes or API changes
>     increase subminor version
>     interface version does not change
>  Minor release (1.X.0) - API changes and bug fixes
>     increase minor version
>     interface version does not change
>   Minor or Major release (1.X.0 or X.0.0) - ABI and API changes
>     increase version
>     increase interface version to match.
> 
> Base/Gui stable release:
>   Subminor release (1.18.X) - bug fixes only
>     increase subminor version
>     interface version does not change
>  Minor release (1.X.0) - ABI, API changes and bug fixes
>     increase minor version
>     interface version changes to match
>   Minor or Major release (1.X.0 or X.0.0) - ABI and API changes
>     increase version
>     increase interface version to match.





reply via email to

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