On 1/27/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > As I said in the vote only three bugfixes were into 2.0.1 to make it > more stable and prevent new funtionality that could bring new bugs.
My bad for not reading your original mail. I was particularly surprised, in particular because of MASSEMBLY-19. It was a one line fix, that I reported as critical. Surprisingly it wasn't considered for 2.0 and I didn't expect it to miss 2.0.1. It's also confusing because I've had this issue fixed in my local install under the 2.0.1-SNAPSHOT release name. So it became obvious for me that the issue would be in 2.0.1. I believe it's the reporter's job to make sure the developers are not missing something important. Unfortunately, if the voting decision is taken too quickly on the developer list, it's hard for a reporter to stay up to date! There are potentially 2 process issues: 1- the trunk was branched, but the pom version still indicated 2.0.1-SNAPSHOT. It should maybe have indicated 2.1-SNAPSHOT. 2- the reporters had little chance of raising their voices. Regarding 2), what about using a 'future' release number in Jira to make sure every issue is at least targeted to a particular release? Before planning a release, the release manager must make sure each reported issue has a target version. The reporter would receive a mail and may react upon it. Jerome --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
