Charles,
> I have just added 2.1a1 as a version. -1. Please revert this. This is something I didn't request. Alphas, betas, and release candidates should not be specified as part of the major version number in a bug system. Aside from simply increasing the number of values for an important field (hence making searches/categorization more onerous), it doesn't serve any useful purpose. It also makes it more difficult to i) evaluate the bugs that need to be evaluated before final release and ii) list the bugs that actually are present in the release, post official release. > Do we want to add 2.1 and 3.0 before they are released? It could make > life confusing for bug reporters and for us. > I suggest we add new versions to Bugzilla as part of the release cycle. Absolutely. The versions that should be added to Bugzilla should be 2.1 and 3.0. They should be added now. 2.1 will allow us to record user and developer discovered issues in 2.1. 3.0 will allow us to record bugs discovered in the course of developing 3.0. The actual Release is the middle of the game, not the beginning. Right now the bug system is effectively useless for accurately recording James bugs. That's one of the reasons that nobody uses it (I think I've recorded over half the new bugs in Bugzilla since August, and there have been a lot more bugs than that). Fixing this would go a small way towards making it more usable. Properly designed bug systems always include version numbers pre-release. That allows developers working on a particular release to record bugs found in new features, bugs in old features being improved, or bugs just exposed via the results of new test cases. If it is necessary to include a notation that the bug was discovered pre-release, either a "stage" (pre-release/post-release) or a minor version (alpha#, beta#, rc#) field is appropriate. Ask yourself the following question. How would I have recorded a bug found in FetchPOP in September? Version unspecified? Not very useful. Version 2.0a3? This feature wasn't even present in that version. The correct answer was (and should've been) 2.1, as that indicates both the time of discovery (sometime in the 2.1 cycle) and allows committers to easily evaluate the relevant bugs when considering release. It also allows users to discover which bugs remain in their version post-release. There's a lot of room for additional improvement in the bug system (i.e found-in vs. fixed-in versions, etc.) but this alone would make accurate bug reporting easier. > Also, would it be useful to add Mailet API versions e.g. API_1.0 etc.? A full revisit of the component list is probably appropriate early in the 3.0 cycle. I'd rather we did this all at once, rather than piecemeal. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
