Peter, > > I have just added 2.1a1 as a version. > > -1. Please revert this. > > This is something I didn't request.
Perhaps not, but everything is not up to you alone. > Alphas, betas, and release candidates > should not be specified as part of the major version number in a > bug system. Says whom? and why? if rc's are released in order for testing it makes perfect sense to include them in the bug system. I don't know where you've worked but ever release I've participated in, on whichever side of the fence, has had alpha beta and rc's in the bug system because the versions change quickly and so we can know which version the tester was using. > 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 serves to allow develoeprs to identify the codebase in which the bug has been identified, surely. > > 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. Yes 2.1 and 3.0 and 3.0 as a milestone. it is also IMO reasonable to have point versions specified in milestones too. > Right now the bug system is effectively useless for accurately recording > James bugs. A bit of unneccessary hyperbole there I think. > 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, Or even 2.1a1 to give us even more precision, by your standards it may have been fixed by chance in 2.1rc1, and you'd have no way of telling. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
