On Wed, Nov 5, 2008 at 10:51 AM, Anselm wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
><br>
<br>
</div>So the implication here is that if a patch potentially causes backward<br>
compatibility problems with existing modules, then it should be moved to the<br>
next major release, while issues that are clearly fixing bugs can remain in<br>
the current release.<br>
</blockquote><div><br>Almost. Issues fixing bugs that are still bugs in the next major release should always be fixed in that release first, then backported to Drupal 6 and/or Drupal 5.<br><br>That way, we don't have bugs fixed in Drupal 6 which then crop up again in Drupal 7, and there's also much more active development there, which generally means more people available to review and refine proposed fixes for any given issue.<br>
<br>When this works well, it means that fixing the bug in Drupal 6 can be as simple as committing the same patch to that branch, or a quick re-roll and commit - this is much harder to do the other way 'round.<br><br>If the code has completely changed in the next release up, then it's fine to keep them where they are of course - but that's also worth noting in the issue. If you find patches posted against Drupal 6 which ought to be fixed in Drupal 7 first, moving them up a release is valuable in itself - the 'patch queue' defaults to Drupal 7, so those of us who rely on that to keep with things only see stuff that's in there unless we're pointed to something specifically.<br>
<br>Nat</div></div><br>