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 18:48:01 GMT
>> 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





Mime
View raw message