Hi David,You can edit the issue and mark it as fix for 2.0.0 and 1.3 (which it already is) and mark it as affects versions 2.0.0 and 1.3 (which it isn't yet).
There's no succinct way to indicate tell the patch has been applied to the trunk except by reading the svn log that's part of the issue and reading your comments.
1.3 is an open release (no release manager watching it) so feel free to apply the patch to 1.3.x also.
I agree with you that the process isn't perfect with regard to applying this fix to other branches. I don't know what more guidance we should offer committers with a patch like this.
Craig On Apr 28, 2009, at 2:45 PM, David Ezzio wrote:
Hi Craig,In some cases the process starts differently. A fix is needed for branch 1.1, and to be polite (and conforming) it is also applied to trunk. So then, what's the process for the 1.2 and 1.3 branches in this case? It seems unfair that the person fixing 1.1 and trunk should also fix (really nag and fix) every other branch, and it seems inefficient that the branch managers be left to fend for themselves in determining which fixes applied to trunk might be of interest to them. And when is the JIRA issue closed?Hmm. I missed how to indicate in the JIRA that a problem is fixed in a particular branch but still pending as a problem for other branches. Could you take a look at 1002, and tell me how to indicate that the problem is fixed for 2.0, but remains unfixed for 1.3?Cheers, David Craig L Russell wrote:Hi David, On Apr 28, 2009, at 1:43 PM, David Ezzio wrote:I'd say you start with trunk and work backwards, recommending that the fix be applied to 1.3.x and if you get any pushback, then stop. If it's ok for 1.3.x, then try 1.2.x. Rinse and repeat.Hi Craig, I'm not sure I understand the following:"Fixes which are committed to an earlier release should also be present 'up-stream'. Ie a fix for 1.0.x should also appear in 1.2.x."I'm unclear about who should make it appear in the upstream releases. In other words, I apply a fix today to trunk and to 1.1.x (with approval). Who applies the fix to 1.2.x and 1.3.x?And how do we track all the branches where a fix has been, should, or should not be applied.I think JIRA actually does support the issue being fixed in multiple releases. I don't know of a simpler way than marking the JIRA with multiple releases.Ideally, the JIRA would do this work for us, but maybe there's a simpler way.CraigThanks, David Craig L Russell wrote:Hi,I think it would be a good idea to formalize OpenJPA's policy with regard to maintenance branch responsibilities. The draft is published at http://cwiki.apache.org/confluence/display/openjpa/OpenJPA+Release+Management for review/comment. Feel free to comment by either posting on the wiki or discussing on this email thread. Once we have consensus, the wiki will be considered policy.Thanks, Craig Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
