On 9/18/06, Michelle Cox <mcox@charter.net> wrote:
On 9/16/2006 2:35:50 PM, Chris Johnson (chris@tinpixel.com) wrote:
Khalid B wrote:
Another problem is that we often don't know if the next release will be an x+1.0 or x.y+1, so we can't say "ported for 5.0" before Dries makes that decision. This is another case where code names for future releases will help.
That is probably the single best argument I've seen for code naming releases before they are released -- so we can refer to them easily and accurately in documentation of all kinds (project pages, CVS comments, postings, etc.).
It's been named 5.0 for a while and is far from released. I'm not a dev, so maybe I'm off base here, but I don't see a big need to have a definite name before the code freeze...
Before it was named, it is known as HEAD (technically, trunk, but that is the name that is used). It was commonly referred to as 4.8/5.0, and the naming happens when all the features are in, and a code freeze happens. At that time Dries decides if it is x.y+1 or x+1.0. However, during the development cycle (from the time the previous release is branched, until that final naming, we use HEAD, and that is a moving target by definition. If someone writes a piece of documentation or refers to the next release as "HEAD" there is no way to know whick release this ended up in. So, what I am advocating is neutral, non-geek code names (flowers, plants, fish, ...etc.) for the upcoming branch. If we say the next release is red rose, or anglefish, then we have a point of reference until it is named 5.1 or whatever. This should really be a separate thread, but ...