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:48:53 GMT
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
> >
>
>

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