<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 12/01/2015 10:16 AM, Christian Lohmaier wrote: </div> <blockquote cite="mid:CAOPHaVQd+2bEx+OPKsY660fDWCc7bM43sPsRN3+gbubWMNM-sQ@mail.gmail.com" type="cite"> <pre wrap="">5.0.0.3 and 5.0.0.4 beta2: 42 </pre> <pre wrap=""> between rc3 and rc4 As long as the merge-to-one-version indicates what version was set prior to the unification, I don't see the information loss, but it should be a standardized comment, so that you could still use queries for those versions. </pre> </blockquote> Ah I see the confusion here. I'm talking about cases where after the merge happens we are asking users to go back and download archived versions to try to narrow down where their regression was introduced. I agree that if the version was already set to begin with then it's not a big deal, but after the merge happens, if we're asking users to "narrow down the regression 'as much as possible'" but then we are taking away their ability to actually set the version...that seems like a problem and pretty confusing. This is why the 6 month rule IMHO makes sense. This gives QA 6 months to triage the bug, try to determine if it's a regression, and try to get users to assist as much as possible by narrowing down the version to the most precise possible (absent bibisecting/bisecting). After 6 months it probably is a lot less likely that the user would care enough to test the bug against older versions so it makes sense to purge at this point. 2-3 months turnaround is IMHO too short when it can take 60 days just to triage the bug (before there is a single touch by QA). Best, Joel </body> </html>