Re: Making release of gui 1/13/2007

[Richard Frith-Macdonald]

On 29 Dec 2006, at 09:20, Richard Frith-Macdonald wrote:

> On 29 Dec 2006, at 08:49, Yen-Ju Chen wrote:
>
> > On 12/29/06, Richard Frith-Macdonald <address@hidden>  
> > wrote:
> > > 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
> >
> >  I think the gnustep-base is stable and mature enough to do so,
> >  but gnustep-gui may not be.
> >  Many fix to gnustep-gui still break the backward compatibility.
> >  So my suggestion is to make it happen for gnustep-base first.
> >  Once everything goes smoothly after a couple cycles,
> >  it will be pretty easy to do the same thing on gnustep-gui and  
> > gnustep-back.
>
> Sorry, I think I caused confusion by raising a second issue  
> (maintaining backward abi compatibility) when discussing general  
> release policy.  I should have stuck to the point.  Yes, it's  
> impractical to attempt to maintain backward compatibility for new  
> releases of the gui any time soon.
>
> However, I don't think that is relevant to a general release policy  
> of maintaining (and publicising) separate stable/bugfix and  
> unstable/trunk release, and making the stable releases very frequent.

Oops ... terminology slip/error.   I meant frequent bugfix  
releases ... I think you would call the initial release 'stable' and  
all releases from the same branch 'bugfix'
So I'm advocating ...

Very infrequent stable releases with very frequent bugfix releases
Moderately paced unstable releases, with daily snapshots and/or very  
frequent unstable subminor releases