openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Lee <allee8...@gmail.com>
Subject Re: [DISCUSS] release openjpa-2.2.0?
Date Fri, 06 Jan 2012 17:41:28 GMT
Mark,

You are advocating a 2.2.x maintenance release. Per Kevin's note on service
branch management, do you have a need to "own" that release for your
product servicing need?

We have the same service requirement based on trunk right now. If you need
owning the 2.2.1 service branch, we can create a separate 2.2.2 after 2.2.1
is completed. Otherwise we can be the release owner of the 2.2.1 branch.

Albert Lee.

On Fri, Jan 6, 2012 at 10:02 AM, Kevin Sutter <kwsutter@gmail.com> wrote:

> Hi Mark,
> You're on the right track.  You can browse the OpenJPA svn repository to
> see how we've done it in the past.  For example, each of our major releases
> is always tagged:
>
> https://svn.apache.org/repos/asf/openjpa/tags
>
> And, corresponding to most of these releases is a service branch:
>
> https://svn.apache.org/repos/asf/openjpa/branches
>
> Mainline development continues on trunk.  So, once we cut the 2.2.0
> release, then trunk becomes 2.3.0-SNAPSHOT.  That is, trunk is working
> towards the next 2.3.0 release.
>
> Each of the service branches has an owning manager.  That manager normally
> creates and maintains that service branch.  Nothing goes into that service
> branch without the owning manager's signoff.
>
> This approach allows multiple organizations to own their service branches,
> if desired.  So, after the 2.2.0 release is complete, we normally create
> the 2.2.x service branch.  But, if there is a reason for you to maintain a
> 2.2.0-mt service branch, there is nothing stopping you.  It's quite
> flexible.
>
> At some point, there may be a determination to also create a service
> release off the branch.  For example, you'll notice that we have created a
> 2.1.1 release based off the 2.1.x service branch.
>
> Make sense?  This is the approach we have used for several releases and
> it's been working for the OpenJPA development team.
>
> Here are a few links that help describe our process:
> http://openjpa.apache.org/release-management.html
> http://openjpa.apache.org/openjpa-release-policy.html
>
> Kevin
>
> On Fri, Jan 6, 2012 at 6:01 AM, Mark Struberg <struberg@yahoo.de> wrote:
>
> > To not let this slip.
> >
> >
> > What are the release plans in general? Do you like to start with the work
> > on the new JPA spec soon (guess this might take another year to get
> > finished). I'd rather keep the trunk as main development stage and would
> > like to work towards a 2.2.1 afterwards on trunk.
> >
> > The reason why I ask this is for the branch we like to create. It's a
> > difference if we just create a '2.2.0-mt' branch (mt for maintenance)
> only
> > for getting 2.2.0 out of the door, and continue our main development
> effort
> > on trunk. Or if we create a '2.2.x' branch and do the most work there
> (and
> > need to merge all work over to trunk).
> >
> > I'm +1 for 2.2.0-mt
> >
> > If noone objects then I like to start this new branch middle of next
> week.
> > What work needs to be done until then? My gut feeling says:
> >
> > * review open JIRAs
> >   * verify and resolve the ones already fixed
> >   * update the fix-version to 2.2.1 for the others
> > * run the TCK
> > * verify/update the documentation of new features.
> >
> > This reminds me that our pdf doesn't contain good information for the new
> > openjpa-maven-plugin. I was also not able to find where we deploy the
> > plugin documentation to. This is imo something we should review/fix
> before
> > we branch.
> >
> >
> > feel free to add missing tasks.
> >
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> > > From: Mark Struberg <struberg@yahoo.de>
> > > To: "dev@openjpa.apache.org" <dev@openjpa.apache.org>
> > > Cc:
> > > Sent: Wednesday, January 4, 2012 8:11 PM
> > > Subject: Re: [DISCUSS] release openjpa-2.2.0?
> > >
> > > I'd just branch the trunk and remove JEST later. Or just keep it and
> > mark it
> > > as 'experimental' - doesn't hurt!
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > > ----- Original Message -----
> > >>  From: Kevin Sutter <kwsutter@gmail.com>
> > >>  To: dev@openjpa.apache.org; Donald Woods <dwoods@apache.org>
> > >>  Cc:
> > >>  Sent: Wednesday, January 4, 2012 7:41 PM
> > >>  Subject: Re: [DISCUSS] release openjpa-2.2.0?
> > >>
> > >>  Donald,
> > >>
> > >>>   I would suggest someone verifying a clean TCK run before we branch.
> > >>>
> > >>
> > >>  Excellent idea.  We used to have someone from the Apache community do
> > this
> > >>  for us since not everybody has access to the TCK.  Is there someone
> > that
> > >>  can step up to do this?
> > >>
> > >>
> > >>>
> > >>>   Also, are there any samples or experimental code that needs to be
> > > removed
> > >>>   or cleaned up before we create a 2.2.0 release?
> > >>>
> > >>
> > >>  Since you brought this up...  I'm think we need to re-think the JEST
> > > module
> > >>  that is currently in trunk.  Pinaki originally put it into trunk with
> > the
> > >>  hopes of solidifying it before we do another release.  I don't think
> > > that
> > >>  effort has transpired.  Since it's a separate module, maybe it can be
> > >>  pulled before creating the 2.2.0 release and 2.2.x service stream and
> > then
> > >>  put back into trunk?  Other ideas?
> > >>
> > >>  Kevin
> > >>
> > >>
> > >>>
> > >>>   -Donald
> > >>>
> > >>>
> > >>>
> > >>>   ________________________________
> > >>>    From: Mark Struberg <struberg@yahoo.de>
> > >>>   To: openjpa-dev <dev@openjpa.apache.org>
> > >>>   Cc: David Blevins <david.blevins@gmail.com>
> > >>>   Sent: Wednesday, January 4, 2012 12:11 PM
> > >>>   Subject: [DISCUSS] release openjpa-2.2.0?
> > >>>
> > >>>   Hi folks!
> > >>>
> > >>>   I've now used openjpa-2.2.0 excessively and it looks very good to
> > > me.
> > >>>   What do you think about going forward and shipping a 2.2.0?
> > >>>   Or at least a RC1...
> > >>>
> > >>>   OpenEJB and Geronimo are waiting for an openjpa-2.2.x release as
> well
> > > ;)
> > >>>
> > >>>   LieGrue,
> > >>>   strub
> > >>>
> > >>
> > >
> >
>



-- 
Albert Lee.

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