[Dev] Milestone numbering going forward

[Katie Capps Parlante]

Philippe Bossut wrote:
> The problem I see with both is that there's potentially a long dry 
> period between feature releases available to users. Users who care about 
> new features will have to pick one of the milestone, say 0.7mx.

Yes, users would pick up 0.7Mx (or 0.7alphax) -- no long dry period. I 
think this would be an honest appellation of what we'd be asking the 
user to try out, and reasonable for a pre-1.0 project.

> Now, let's say that such a milestone is successful (if we get users... 
> ;) ) but has a horrible bug in it. In the meantime, Tinderbox is on fire 
> and 0.7m(x+1) can't be produced before weeks. What do we do? We'll have 
> to create an 0.7mx-r8401 off the 0.7mx branch.

That is no worse than a 0.6.0-r8401, imho.

> So, when said and done, the topology and length of the branches of the 
> tree will be the same as the (2-Forward) proposal. The difference will 
> be that:
> - we won't have much 0.6.x updates
> - we'll be using longish revision names moving toward 0.7

I think you mean (2-Backward)?

> My personal opinion is that, if we go with a "stable high quality 
> milestones" dev process, because our early adopters will all care for 
> new features, they'll pick those and the 0.6 name space will have a very 
> short lifetime. We may even get to a point where we will recommend to 
> users to download 0.7alphax (because perfs are better or security or 
> whatever) and that sounds weird to me.

Yes, we are in agreement that early adopters interested in new features 
will pick stable milestones and that the 0.6 derivations will have a 
short lifetime -- in our ideal scenario here.

Yes, I'm saying that users should download 0.7alphax (or 0.7Mx), and 
that doesn't sound weird to me. ;)

Cheers,
Katie