Re: Making release of gui 1/13/2007

[Richard Frith-Macdonald]

On 29 Dec 2006, at 00:37, Fred Kiefer wrote:

> Gregory John Casamento schrieb:
> > I would like to shoot for making a release of gui on 1/13/2007.
>
> I am currently working on a rework of NSDocument to include all the  
> new
> MacOS 10.4 methods. Should I try to get these changes in before the
> release or after it?
>
> These changes need to break backwards compatibility as loads of new
> ivars need to be added. You will have to recompile all applications
> using subclasses for NSDocument.
> As I plan to do similar breaking of backwards compatibility over the
> next few months, it might be worthwhile to group them together into  
> one
> release.

I've been fairly convinced by recent arguments about releases (emails  
from packagers etc) that we make our new releases too frequently, and  
that what we should be doing is making less frequent new releases  
(with new features and api/abi changes), but more frequent bugfix  
releases (ie where no api/abi changes are made, but bugs are fixed).

So I would surely agree with making bugfix releases of gui and back  
early in january (I've been planning to do base anyway), but I think  
we should save all the api/abi changes for a later release somewhere  
six to twelve months away.

Of course the downside if this is that we need to backport bugfixes  
from trunk to the current stable branch of gui/back ... which is  
tedious (but a lot less work than doing the original fixes).

The positive advantage is that by lengthening the interval between  
new releases we can try to make all the api/abi changes we need  
together in one go.  In the base library I would really like to get  
it to a state where we have changed all classes etc so that we no  
longer need to break backward compatibility in any release (ie have  
changed ivar layouts etc so that all classes we are ever likely to  
extend can be extended without changing the size of the instances or  
the nature of any public/protected ivars).  With the gui library that  
may not yet look like a reasonable goal, but we certainly want to be  
able to make future releases without breaking backward compatibility  
if we can.

As far as giving people access to the latest code in trunk goes ...  
we have automated snapshots which provide that.
Or we could adopt a policy of formally having two sets of releases on  
the go, stable and unstable, and make it VERY clear that the unstable  
releases are only for people who are actually willling to contrinute  
bugfixes/patches for any problems they find.
Or we could keep 'preferred'' snapshots on the ftp site ... ie save a  
set of snapshots once a month, so that people can build to a  
particular month's snapshots rather than the daily ones ... and know  
that the set of snapshots they used will remain available on the site  
for (say)  a year, and they can tell people to grab that set of  
snapshots in order to use their application.

My personal preference is for the dual release strategy ... that way  
we can publicise ourselves twice as often ...
once for each stable release, with a nice list of bugs fixed, and a  
prominent message to encourage packagers to update the distribution  
they work with
once for each unstable release, with a list of cool new features, and  
a big message to encourage developers to provide bugfixes/patches