[Dev] Milestone numbering going forward

Philippe Bossut pbossut at osafoundation.org
Wed Nov 30 22:51:09 PST 2005



Katie Capps Parlante wrote:

> Philippe, if I understand correctly you are essentially proposing this 
> with (2-Backward):
>
>      /-0.6.0    /-0.6.1    /-0.6.2   /-0.7.0
>     /          /          /         /
> 0.5.m8----0.6.m1------0.6.m2----0.6.m3-----0.7.m1
>
> Which I find confusing. Also, it doesn't any leave room for updating 
> the 0.6.x releases independently of milestones, should we need it.

It does leave all the room we need: nothing prevents us to create an 
0.6.0-r8401 to fix a security issue for instance. Actually it makes 
clear that 0.6.0-r8401 is a micro bug fix while 0.6.1 is a significant 
step on the road to 0.7.

>
> I am definitely in favor of having stable milestones, and having users 
> follow us on those milestones -- assuming we get some users ;). 
> However, I think this just means that we will stop needing 0.6.x 
> releases once a stable milestone leaves 0.6 in the dust, because we 
> can have users download the milestone release directly. Given that we 
> are a pre-1.0 project, I don't think we need to rigorously keep up 
> parallel 0.6.x releases with milestone releases.
>
> This one, essentially the original proposal, seems pretty rational to 
> me (I believe like Eclipse):
>
>      /-0.6.0--0.6.1              /-0.7.0--0.7.1
>     /                           /
> 0.5M8-----0.7M1------0.7M2----0.7M3-----0.8M1
>
> as does this (Alec's proposal, if I understand correctly):
>
>      /-0.6.0--0.6.1                           /-0.7.0--0.7.1
>     /                                        /
> 0.5alpha8-----0.7alpha1------0.7alpha2----0.7alpha3-----0.8alpha1 

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.

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.

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

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.

Cheers,
- Philippe



More information about the Dev mailing list