[Cosmo-dev] Milestone and general naming, terminology
heikki at osafoundation.org
Tue Aug 29 11:41:55 PDT 2006
Please reply to general newsgroup ONLY, so that we can keep the
discussion on one forum. Reply-to address is set, so you should be able
to just hit Reply in your email client.
Chandler is currently on it's fourth milestone name scheme, and it looks
like we might have a need to change it again for 'beta', and possibly
again after that for '1.0'. I believe the naming schemes are different
between Chandler and Cosmo. It would make sense to unify them because
the current situation is causing confusion.
We also have names for other stages of development, which also seem to
differ between the projects. This is also causing confusion, for example
not knowing just from the use of names how far away from release or
milestone we are.
So, to start with milestone schemes... Chandler currently is proceeding
towards 0.7 Release (0.7alpha1, 0.7alpha2, ... 0.7alpha6, 0.7 Release).
Actually there is also a question: should the 0.7 Release be called 0.7beta?
Once Chandler reaches 0.7 Release, which we also call the Chandler Beta,
are we going to continue with 0.8alpha1, ... or will that change to
0.8beta1? If it changes to beta, what happens when we hit our '1.0' release?
What is Cosmo's milestone numbering scheme?
Next are the terms alpha and beta. Chandler uses alpha to mark a product
that is usable inside of OSAF. Beta is something we want the public to
give a try; think "Google Beta".
I believe Cosmo is using beta to mean feature complete; can you confirm?
I believe we should unify what alpha and beta mean between the projects.
Next item are the stages near a release. I'll describe what we use with
Chandler, since I don't know anything about Cosmo's process yet. These
have come a little fuzzy as of late, and I think we should re-clarify
these. I should point out that all rules can be broken in exceptional
situations (and have been broken in the past) ;)
We have Feature Freeze, which means that no new features or
functionality will be allowed to be checked in. We also require code
reviews before checkin, and all checkins must address a bug that has
been approved by Bug Council to be checked in (the bug is assigned to
the milestone by the Bug Council, or in some cases even marked as
blocking a release). All other stages beyond this point require Bug
Council approval and code review.
After that comes Code Freeze, which means we are ready to create a
Release Candidate for testing. If testing passes, we have a Release. If
it does not pass, we get new bugs filed, which get approved by Bug
Council to be fixed even during the Code Freeze, and roll a new Release
We will soon need Internationalization, or Localization Freeze. Once
this is in effect, no changes will be allowed which affect localization.
Typically this would be somewhere between Feature Freeze and Code Freeze.
We also have Documentation Freeze, which could perhaps be removed from
the process. The idea with Documentation Freeze was that we could enter
Code Freeze but still allow changes to comments, docstrings and the
like. However, I am starting to think that it would simplify the process
if we remove this step and state that everything must be completed by
Some people have also talked about Code Complete, perhaps meaning Code
Freeze, but this is not clear to me. I think we should discourage the
use of this term.
We also sometimes talk about bugs that block a release. Bugzilla also
has a special flag feature that can support this process. As the name
implies, release blocker bugs will delay a release until they are fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20060829/902f5bfb/signature.pgp
More information about the cosmo-dev