openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <mik...@apache.org>
Subject Re: OpenJPA 1.1.0 release planning
Date Tue, 08 Apr 2008 15:00:47 GMT
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.

-Mike


> -Patrick
>
> --
> Patrick Linskey
> 202 669 5907
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message