see below On 1/27/06, jerome lacoste <[EMAIL PROTECTED]> 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.
I took 2.0 code and made a branch fixed the issues I needed at the moment. I expected that if somebody would like to have another bug fixed would talk during the vote > > 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. > trunk is always set to the next release (2.1-SNAPSHOT), maybe it was at some point set to 2.0.1 by mistake when you built it. Anyway you would get the newer snapshot from the repo. > > > 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! I think this one was clear, "only three bugfixes will be applied". I know that there's a lot of traffic in the mailing list, me for instance, I prefer not voting if I'm not really confident, eg plugins i don't use. > > > 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. as i said before trunk was 2.1-SNAPSHOT and has been like that since 2.0 was released > > > 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. I think this is now improved having a jira project per plugin so we can take a clear look to what goes in each revision. Unfortunately there're still several issues fixed in 2.1-SNAPSHOT that don't have a fix version, and that'll be still a problem till 2.1 is released I think it's a good idea if you want other bug fixes, to apply them to the 2.0.x branch and update jira with the fix version. We can call a vote for 2.0.2 after. > > 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]
