Re: Next release

[Gregory Casamento]

I agree that we should delay the release of gui since there have been
a number of changes that have not been fully tested.   While I'm sure
that they are working I have tested them with a limited set of apps
and would like to see a greater degree of testing done prior to an
official release.

The change to NSSplitView is based on the idea that the subviews of
the splitview should always resize themselves since this appears to be
the observed behavior on Cocoa.  I need to do further testing on this,
so I left it in the nib loading code for now.

Regarding inconsistencies between loading from a nib and creating in
code, I'm not sure that the assumption that they should always be the
same is entirely valid.

GC

On 4/15/09, Fred Kiefer <address@hidden> wrote:
> 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.
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>


-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)