You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Craig L Russell <Cr...@Sun.COM> on 2009/04/24 22:37:34 UTC
Proposed maintenance branch policy
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposed maintenance branch policy
Posted by Michael Dick <mi...@gmail.com>.
A couple quick thoughts. I think Craig's pretty much covered it though.
On Tue, Apr 28, 2009 at 5:20 PM, Craig L Russell <Cr...@sun.com>wrote:
> 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.
>
+1. It isn't perfect but I think we have a workable solution.
> 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?
>>
>
I'd say that the issue is closed when the fix has been committed in trunk
and 1.1 (1.3 would be nice too). If a branch maintainer wants to pick up the
fix she/he can reopen the issue or just update the fixes attribute of the
issue.
>
>> 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:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>> Craig L Russell
>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: Proposed maintenance branch policy
Posted by Craig L Russell <Cr...@Sun.COM>.
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:
>>> 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:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposed maintenance branch policy
Posted by David Ezzio <de...@apache.org>.
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:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Proposed maintenance branch policy
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposed maintenance branch policy
Posted by David Ezzio <de...@apache.org>.
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.
Ideally, the JIRA would do this work for us, but maybe there's a simpler
way.
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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Proposed maintenance branch policy
Posted by Michael Dick <mi...@gmail.com>.
Hi Donald,
I might take you up on that. The part that I've never really understood is
how the confluence content is "translated" to the site. I don't know the
content of the wiki, but the Geronimo site seems to mirror the content of
the wiki better than ours does.
Anyway I've derailed this thread enough, thanks for the offer.
-mike
2009/4/27 Donald Woods <dw...@apache.org>
> Thanks! We use several Confluence spaces (site, project mgmt, samples,
> docs, ....) and links to pull it all together....
>
> BTW - If you let me know which pages you're interested in, I can send you
> the wiki markup off-line.....
>
>
> -Donald
>
>
>
> Michael Dick wrote:
>
>> 2009/4/27 Michael Dick <mi...@gmail.com>
>>
>> I think this is the page [1], [2] (wiki, normal).
>>>
>>> Combining that page with the new one, or linking them better (maybe a new
>>> category on the right is in order) is probably also needed. I think
>>> Geronimo
>>> [3] has done a good job with their site - wish I could see the wiki
>>> syntax
>>> to see how they did it ;-).
>>>
>>
>>
>> I should have elaborated here.. I think that we might want to reorganize
>> the
>> overall openjpa site. The two sets of release instructions need to be
>> cleaned up, and I'm sure there are other areas that can be made more
>> visible.
>>
>> Geronimo's site seems well organized and the project management page has
>> similar information to what we're adding now.
>>
>> -mike
>>
>>
>> [1]
>>> http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55076
>>> [2] http://openjpa.apache.org/openjpareleasepolicy.html
>>> [3] http://geronimo.apache.org/
>>>
>>> -mike
>>>
>>>
>>> On Mon, Apr 27, 2009 at 12:01 PM, Craig L Russell <Craig.Russell@sun.com
>>> >wrote:
>>>
>>> Hi Michael,
>>>>
>>>> I think there is a bigger piece missing. I remember we had a discussion
>>>> on
>>>> the branch/tag/release strategy and I can't find it now (perhaps it's an
>>>> orphaned wiki page).
>>>>
>>>> What would make it easier to understand is to have a brief introduction
>>>> to
>>>> the release and maintenance strategy. If no one can find it, I'll create
>>>> it
>>>> from memory and put it into the wiki.
>>>>
>>>> Something like this: OpenJPA releases are numbered with
>>>> major.minor.update
>>>> schemes. Releases have a maintenance branch numbered major.minor.x. Each
>>>> maintenance branch can build the next release in the series, e.g. 1.0.x
>>>> will
>>>> build 1.0.4-SNAPSHOT.
>>>>
>>>> Craig
>>>>
>>>>
>>>> On Apr 27, 2009, at 8:21 AM, Michael Dick wrote:
>>>>
>>>> Would it be easier to read if I put a link to the table? The column for
>>>>
>>>>> contact release manager before committing could be filled in to make it
>>>>> more
>>>>> obvious that the release is open.
>>>>>
>>>>> -mike
>>>>>
>>>>> On Sun, Apr 26, 2009 at 12:29 PM, Craig L Russell <
>>>>> Craig.Russell@sun.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>> Hi Miłosz,
>>>>>
>>>>>> An "open" release is a branch that is still able to be committed to.
>>>>>> Releases that have shipped are not open.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>
>>>>>> On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> Section "Where should I put my fix?", I am not sure what it means,
>>>>>>> "open
>>>>>>> release". Are these 2.0.x and 1.3.x branches currently?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Milosz
>>>>>>>
>>>>>>>
>>>>>>> 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:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Craig L Russell
>>>>>>>>
>>>>>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Craig L Russell
>>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>>
>>
Re: Proposed maintenance branch policy
Posted by Donald Woods <dw...@apache.org>.
Thanks! We use several Confluence spaces (site, project mgmt, samples,
docs, ....) and links to pull it all together....
BTW - If you let me know which pages you're interested in, I can send
you the wiki markup off-line.....
-Donald
Michael Dick wrote:
> 2009/4/27 Michael Dick <mi...@gmail.com>
>
>> I think this is the page [1], [2] (wiki, normal).
>>
>> Combining that page with the new one, or linking them better (maybe a new
>> category on the right is in order) is probably also needed. I think Geronimo
>> [3] has done a good job with their site - wish I could see the wiki syntax
>> to see how they did it ;-).
>
>
> I should have elaborated here.. I think that we might want to reorganize the
> overall openjpa site. The two sets of release instructions need to be
> cleaned up, and I'm sure there are other areas that can be made more
> visible.
>
> Geronimo's site seems well organized and the project management page has
> similar information to what we're adding now.
>
> -mike
>
>
>> [1] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55076
>> [2] http://openjpa.apache.org/openjpareleasepolicy.html
>> [3] http://geronimo.apache.org/
>>
>> -mike
>>
>>
>> On Mon, Apr 27, 2009 at 12:01 PM, Craig L Russell <Cr...@sun.com>wrote:
>>
>>> Hi Michael,
>>>
>>> I think there is a bigger piece missing. I remember we had a discussion on
>>> the branch/tag/release strategy and I can't find it now (perhaps it's an
>>> orphaned wiki page).
>>>
>>> What would make it easier to understand is to have a brief introduction to
>>> the release and maintenance strategy. If no one can find it, I'll create it
>>> from memory and put it into the wiki.
>>>
>>> Something like this: OpenJPA releases are numbered with major.minor.update
>>> schemes. Releases have a maintenance branch numbered major.minor.x. Each
>>> maintenance branch can build the next release in the series, e.g. 1.0.x will
>>> build 1.0.4-SNAPSHOT.
>>>
>>> Craig
>>>
>>>
>>> On Apr 27, 2009, at 8:21 AM, Michael Dick wrote:
>>>
>>> Would it be easier to read if I put a link to the table? The column for
>>>> contact release manager before committing could be filled in to make it
>>>> more
>>>> obvious that the release is open.
>>>>
>>>> -mike
>>>>
>>>> On Sun, Apr 26, 2009 at 12:29 PM, Craig L Russell <Craig.Russell@sun.com
>>>>> wrote:
>>>> Hi Miłosz,
>>>>> An "open" release is a branch that is still able to be committed to.
>>>>> Releases that have shipped are not open.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Craig
>>>>>
>>>>>
>>>>> On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>>> Section "Where should I put my fix?", I am not sure what it means,
>>>>>> "open
>>>>>> release". Are these 2.0.x and 1.3.x branches currently?
>>>>>>
>>>>>> Regards,
>>>>>> Milosz
>>>>>>
>>>>>>
>>>>>> 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:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Craig L Russell
>>>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>>>>
>>> Craig L Russell
>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>
Re: Proposed maintenance branch policy
Posted by Michael Dick <mi...@gmail.com>.
2009/4/27 Michael Dick <mi...@gmail.com>
> I think this is the page [1], [2] (wiki, normal).
>
> Combining that page with the new one, or linking them better (maybe a new
> category on the right is in order) is probably also needed. I think Geronimo
> [3] has done a good job with their site - wish I could see the wiki syntax
> to see how they did it ;-).
I should have elaborated here.. I think that we might want to reorganize the
overall openjpa site. The two sets of release instructions need to be
cleaned up, and I'm sure there are other areas that can be made more
visible.
Geronimo's site seems well organized and the project management page has
similar information to what we're adding now.
-mike
> [1] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55076
> [2] http://openjpa.apache.org/openjpareleasepolicy.html
> [3] http://geronimo.apache.org/
>
> -mike
>
>
> On Mon, Apr 27, 2009 at 12:01 PM, Craig L Russell <Cr...@sun.com>wrote:
>
>> Hi Michael,
>>
>> I think there is a bigger piece missing. I remember we had a discussion on
>> the branch/tag/release strategy and I can't find it now (perhaps it's an
>> orphaned wiki page).
>>
>> What would make it easier to understand is to have a brief introduction to
>> the release and maintenance strategy. If no one can find it, I'll create it
>> from memory and put it into the wiki.
>>
>> Something like this: OpenJPA releases are numbered with major.minor.update
>> schemes. Releases have a maintenance branch numbered major.minor.x. Each
>> maintenance branch can build the next release in the series, e.g. 1.0.x will
>> build 1.0.4-SNAPSHOT.
>>
>> Craig
>>
>>
>> On Apr 27, 2009, at 8:21 AM, Michael Dick wrote:
>>
>> Would it be easier to read if I put a link to the table? The column for
>>> contact release manager before committing could be filled in to make it
>>> more
>>> obvious that the release is open.
>>>
>>> -mike
>>>
>>> On Sun, Apr 26, 2009 at 12:29 PM, Craig L Russell <Craig.Russell@sun.com
>>> >wrote:
>>>
>>> Hi Miłosz,
>>>>
>>>> An "open" release is a branch that is still able to be committed to.
>>>> Releases that have shipped are not open.
>>>>
>>>> Regards,
>>>>
>>>> Craig
>>>>
>>>>
>>>> On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
>>>>
>>>> Hi!
>>>>
>>>>>
>>>>> Section "Where should I put my fix?", I am not sure what it means,
>>>>> "open
>>>>> release". Are these 2.0.x and 1.3.x branches currently?
>>>>>
>>>>> Regards,
>>>>> Milosz
>>>>>
>>>>>
>>>>> 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:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Craig L Russell
>>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
Re: Proposed maintenance branch policy
Posted by Michael Dick <mi...@gmail.com>.
I think this is the page [1], [2] (wiki, normal).
Combining that page with the new one, or linking them better (maybe a new
category on the right is in order) is probably also needed. I think Geronimo
[3] has done a good job with their site - wish I could see the wiki syntax
to see how they did it ;-).
[1] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55076
[2] http://openjpa.apache.org/openjpareleasepolicy.html
[3] http://geronimo.apache.org/
-mike
On Mon, Apr 27, 2009 at 12:01 PM, Craig L Russell <Cr...@sun.com>wrote:
> Hi Michael,
>
> I think there is a bigger piece missing. I remember we had a discussion on
> the branch/tag/release strategy and I can't find it now (perhaps it's an
> orphaned wiki page).
>
> What would make it easier to understand is to have a brief introduction to
> the release and maintenance strategy. If no one can find it, I'll create it
> from memory and put it into the wiki.
>
> Something like this: OpenJPA releases are numbered with major.minor.update
> schemes. Releases have a maintenance branch numbered major.minor.x. Each
> maintenance branch can build the next release in the series, e.g. 1.0.x will
> build 1.0.4-SNAPSHOT.
>
> Craig
>
>
> On Apr 27, 2009, at 8:21 AM, Michael Dick wrote:
>
> Would it be easier to read if I put a link to the table? The column for
>> contact release manager before committing could be filled in to make it
>> more
>> obvious that the release is open.
>>
>> -mike
>>
>> On Sun, Apr 26, 2009 at 12:29 PM, Craig L Russell <Craig.Russell@sun.com
>> >wrote:
>>
>> Hi Miłosz,
>>>
>>> An "open" release is a branch that is still able to be committed to.
>>> Releases that have shipped are not open.
>>>
>>> Regards,
>>>
>>> Craig
>>>
>>>
>>> On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
>>>
>>> Hi!
>>>
>>>>
>>>> Section "Where should I put my fix?", I am not sure what it means, "open
>>>> release". Are these 2.0.x and 1.3.x branches currently?
>>>>
>>>> Regards,
>>>> Milosz
>>>>
>>>>
>>>> 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:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>>>>
>>>>> Craig L Russell
>>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: Proposed maintenance branch policy
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
I think there is a bigger piece missing. I remember we had a
discussion on the branch/tag/release strategy and I can't find it now
(perhaps it's an orphaned wiki page).
What would make it easier to understand is to have a brief
introduction to the release and maintenance strategy. If no one can
find it, I'll create it from memory and put it into the wiki.
Something like this: OpenJPA releases are numbered with
major.minor.update schemes. Releases have a maintenance branch
numbered major.minor.x. Each maintenance branch can build the next
release in the series, e.g. 1.0.x will build 1.0.4-SNAPSHOT.
Craig
On Apr 27, 2009, at 8:21 AM, Michael Dick wrote:
> Would it be easier to read if I put a link to the table? The column
> for
> contact release manager before committing could be filled in to make
> it more
> obvious that the release is open.
>
> -mike
>
> On Sun, Apr 26, 2009 at 12:29 PM, Craig L Russell <Craig.Russell@sun.com
> >wrote:
>
>> Hi Miłosz,
>>
>> An "open" release is a branch that is still able to be committed to.
>> Releases that have shipped are not open.
>>
>> Regards,
>>
>> Craig
>>
>>
>> On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
>>
>> Hi!
>>>
>>> Section "Where should I put my fix?", I am not sure what it means,
>>> "open
>>> release". Are these 2.0.x and 1.3.x branches currently?
>>>
>>> Regards,
>>> Milosz
>>>
>>>
>>> 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:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposed maintenance branch policy
Posted by Michael Dick <mi...@gmail.com>.
Would it be easier to read if I put a link to the table? The column for
contact release manager before committing could be filled in to make it more
obvious that the release is open.
-mike
On Sun, Apr 26, 2009 at 12:29 PM, Craig L Russell <Cr...@sun.com>wrote:
> Hi Miłosz,
>
> An "open" release is a branch that is still able to be committed to.
> Releases that have shipped are not open.
>
> Regards,
>
> Craig
>
>
> On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
>
> Hi!
>>
>> Section "Where should I put my fix?", I am not sure what it means, "open
>> release". Are these 2.0.x and 1.3.x branches currently?
>>
>> Regards,
>> Milosz
>>
>>
>> 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:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: Proposed maintenance branch policy
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Miłosz,
An "open" release is a branch that is still able to be committed to.
Releases that have shipped are not open.
Regards,
Craig
On Apr 26, 2009, at 12:11 AM, Miłosz Tylenda wrote:
> Hi!
>
> Section "Where should I put my fix?", I am not sure what it means,
> "open release". Are these 2.0.x and 1.3.x branches currently?
>
> Regards,
> Milosz
>
>
>> 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:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposed maintenance branch policy
Posted by Miłosz Tylenda <mt...@o2.pl>.
Hi!
Section "Where should I put my fix?", I am not sure what it means, "open release". Are these 2.0.x and 1.3.x branches currently?
Regards,
Milosz
> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>