openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Re: OpenJPA 1.1.0 release planning
Date Tue, 08 Apr 2008 19:51:15 GMT
FYI, I just created a branch for 1.1.x and changed the trunk version  
number to 1.2.0-SNAPSHOT. I'll add a page to the wiki describing the  
release goals for 1.1.0 at some point in the next few days. Meanwhile,  
the general gist is that we should restrict the 1.1.0 branch to  
hardening work in general.

-Patrick

On Apr 8, 2008, at 1:48 PM, Patrick Linskey wrote:
>>> Having trunk(2.0.x), 1.1.x, 1.2.x, and 1.0.x  seems about right.
>
>>> I don't particularly like adding branches and dual / triple  
>>> maintenance.
>>> If anyone has a better idea I'm open to suggestions.
>
> I think that we can create these branches lazily -- that is, I don't  
> think that we need to have both 1.2.x and 2.0.x if we aren't working  
> on things for 2.0 that would be disruptive for 1.2. I think that  
> that could help mitigate the branching overhead.
>
>> I was thinking of it as more
>> of an ongoing release manager role for the consumer that proposed the
>> release.
>
>
> I think that we (BEA) definitely are in favor of a "branch manager"  
> sort of situation, in which the branch manager has additional  
> responsibilities.
>
> -Patrick
>
> On Apr 8, 2008, at 10:48 AM, Michael Dick wrote:
>> Minor edit below
>>
>> On Tue, Apr 8, 2008 at 10:00 AM, Michael Dick <mikedd@apache.org>  
>> wrote:
>>
>>> On Fri, Apr 4, 2008 at 2:22 PM, Patrick Linskey <plinskey@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We (BEA) would like to get a 1.1.0 release underway so that we can
>>>> release off of the 1.1.x line for our upcoming WebLogic Server
>>>> release. Soooooo:
>>>>
>>>> - Any objections to getting the process under way to make a 1.1.0
>>>> release?
>>>
>>>
>>> No objections from me. We're probably about due for another trunk  
>>> release.
>>> What sort of timeframe were you thinking? Would the end of April /  
>>> beginning
>>> of May work for you?
>>>
>>>
>>>> - The first step is to do some JIRA issue triage work to figure out
>>>> what needs to be in 1.1.0 and what can be deferred. If you have  
>>>> issues
>>>> you know of that you feel strongly about one way or another,  
>>>> now's the
>>>> time to set the release information in JIRA appropriately.
>>>
>>>
>>> Will do.
>>>
>>>
>>>>
>>>> - We (BEA) will want to keep the 1.1.x branch to a minimal set of
>>>> critical changes; I think that we're a bit more conservative about
>>>> changes than what has happened in the 1.0.x branch so far. I'm
>>>> guessing that over time, different OpenJPA consumers will have
>>>> different needs in terms of branch lifecycles and update  
>>>> policies; any
>>>> thoughts about how to codify this so that people know how  
>>>> conservative
>>>> a particular branch should be?
>>>>
>>>
>>> I agree and I've been thinking about this a bit too. I think we need
>>> another branch in the mix. Right now trunk contains the ongoing  
>>> code for the
>>> next major release and minor release. As a result we've blurred  
>>> the lines
>>> between the two (and it flowed over into 1.0.x as well).  Having
>>> trunk(2.0.x), 1.1.x, 1.2.x, and 1.0.x  seems about right.
>>>
>>> Then when a consumer proposes a release of OpenJPA they can also  
>>> be the
>>> final arbiter of which fixes go into the corresponding branch. For  
>>> example
>>> if BEA sponsors the 1.1.0 branch then the rest of us will play  
>>> nice and not
>>> port fixes without approval. Other consumers can confine their  
>>> changes to
>>> 1.2.x, or trunk (as appropriate).
>>>
>>> I don't particularly like adding branches and dual / triple  
>>> maintenance.
>>> If anyone has a better idea I'm open to suggestions.
>>>
>>
>> The original proposal might sound more draconian than I intended it  
>> to be.
>> I'm not proposing a petition that *only* the party that proposed a  
>> release
>> can make changes in the corresponding branch. I was thinking of it  
>> as more
>> of an ongoing release manager role for the consumer that proposed the
>> release.
>>
>> Also note consumers in this context should not be limited to the
>> organizations on the "powered by" page either, IIRC Geir was one of  
>> the
>> leading advocates for  the 1.0.2 release. In that respect he could be
>> considered a consumer (or sponsor which sounds a little nicer).
>>
>> -Mike
>>
>>
>>> -Mike
>>>
>>>
>>>> -Patrick
>>>>
>>>> --
>>>> Patrick Linskey
>>>> 202 669 5907
>>>>
>>>
>>>
>
> -- 
> Patrick Linskey
> 202 669 5907
>
>
>
>

-- 
Patrick Linskey
202 669 5907





Mime
View raw message