Most of the fixes were made after large refactoring of the code so were hard to backport. We picked out ones known to be affecting people.
Normally, we'd have better track of what versions the issues related to, but since we only split out the JIRA projects recently, we didn't know which were in 2.0 and which were more recent. The vote was out for over 72 hours, which is somewhat of a standard measurement. The only improvement would have been to be more explicit about the limits of the changes. The trunk has been at 2.1-SNAPSHOT for quite some time. 2.1 won't be far off. The issues are now correctly scheduled. - Brett jerome lacoste wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
