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:
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!
