Peter M. Goldstein wrote:
Charles,
I have just added 2.1a1 as a version.-1. Please revert this.
Done
I think we can use the "Milestones" field to distinguish where in the 2.1 cycle a bug is. This has only recently been activated, so there are no entries for James.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.
How about:
pre-alpha, alpha1, alpha2..., beta#, rc#, etc?
For now, I've added 2.1 and 3.0 as versions, and pre-alpha and alpha1 as 'Milestones'.
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.
Fine by me Charles -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
