Hi David, On Apr 28, 2009, at 1:43 PM, David Ezzio wrote:
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?
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.
And how do we track all the branches where a fix has been, should, or should not be applied.Ideally, the JIRA would do this work for us, but maybe there's a simpler way.
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.
Craig
Thanks, 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!
smime.p7s
Description: S/MIME cryptographic signature
