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