Bert wrote:
> The real problem with frequent releases is that each time we release 
> something, we diminish the number of users / developers 
> working in one release. That means older versions are never fixed,
> but just dumped. Doing a 2-year project? Yeah, sorry, that's too old,
> we don't support this anymore.

This problem could be addressed by providing update paths which allow users
to go from x.y to x.y+1 (which is why I was referring to it). It makes sense
if you don't want to  manage forked update streams. 

Doug wrote:
> Well actually, the split to the x.y+1 alpha stream often happens
> back when x.y goes to beta or gamma, so the split can still be 
> useful if we want to add different things to x.ybeta and x.y+1alpha
> at the same time.

True but not a "good enough" reason ;-) You could simply declare that
nothing is going to be put into alpha before gamma is finalized. What
difference does it make if some (alpha!) stuff gets posted a week earlier or
later? And yes, it would mean that you'll get "some alpha stuff" along with
some other fixes but I think that (considering the current guides policy of
extensive reviews) this isn't going to be a big issue.

Cheers,
  - Andreas