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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
