Re: gnustep release numbers

[Richard Frith-Macdonald]

On 4 Oct 2006, at 21:45, Hubert Chan wrote:

> On Wed, 4 Oct 2006 21:28:49 +0200, Helge Hess  
> <address@hidden> said:
>
> > On Oct 4, 2006, at 18:42, Richard Frith-Macdonald wrote:
> > > > Note: by 'unstable' I don't mean that the code itself is buggy but
> > > > that the ABI is unstable.
> > > Fair enough ... that's your definition ... but it's rather an  
> > > unusual
> > > one.
>
> > Really? I think thats the term usually used by OpenSource
> > projects. But anyway ;-)
>
> > Stability is an inherent requirement for Linux distributions because
> > they can't change the ABI constantly. Which makes it a cycle of ~2
> > years for all (serious) distributions. But at least 12 months.
> Yes, I agree.  Having the ABI change frequently is a challenge for the
> Debian packaging team, since it means that every time a new GNUstep
> release is made, we have to recompile all our packages.
>
> Is there any reason we need to change the ABI all the time?
>
> (AFAIK, glib/gtk+ hasn't changed their ABI since glib/gtk+ 2.0 was
> released, so any old program that was compiled back then will still  
> run
> on a newer system.)

There is a tension between those who ask for more frequent releases  
(because they want new features) and those who ask for less frequent  
releases because they have some issue with keeping multiple releases  
on disk (you never need to recompile programs for a new release if  
you keep the old libraries ... that's what library versioning is for).

I think we are trying to make more frequent releases than we used  
to ... eg  once every six months, because (unscientific estimate)  
there seem to be more complaints about there being too few releases  
than about there being too many.

Actually, my sympathy with either complaint is limited ...
People who complain about too few releases always have the option of  
using SVN trunk or snapshots with very little extra work required.
People who complain about too many releases can always keep multiple  
releases on their system or simply skip releases now and then, only  
upgrading  with bugfix releases for the main release they are using.

And as long as the complaints from both groups are roughly equal,  
we've probably got the actual release rate about right.