It sounds to me from this discussion that it's not a question of forward
*or* backward, but forward *and* backward numbering. If we release a new
version of an old branch, that's a postrelease tag on the old version
number. If we release an in-development milestone of a future version,
that's a prerelease tag. Whether these are done from the trunk or a branch
makes relatively little difference, as does whether we use 0.7dev.m1 or
0.7a1 to designate a prerelease milestone of 0.7.
I personally find the scheme we've been using to be odd, because it doesn't
reflect our *goals*. In my view, we've been working on early (i.e.
pre-release) versions of 0.6, and now we'll be working on pre-releases of
0.7 until we're ready to release 0.7. I don't actually know what is meant
in this discussion by "forward" or "backward" versioning, because those
terms don't make sense to me either. The numbers don't go forward or
backward, we are simply issuing either pre-releases or post-releases. What
we *have* been doing is giving post-release version numbers for our
pre-release versions. We should simply be clear about the difference
between the two.
At 11:06 PM 11/30/2005 -0800, Katie Capps Parlante wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
