openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [DISCUSS] release openjpa-2.2.0?
Date Fri, 06 Jan 2012 16:23:58 GMT
Given we have some cleanup work, I'd suggest we create a branch from trunk as openjpa/branches/2.2.x
which can then be used to release 2.2.0 and future maintenance streams for 2.2.x.  Then,
trunk would become 2.3.0-SNAPSHOT.

As far as new JPA spec work, we can decide later if we use 2.3 or move 2.3 to a branch and
upgrade Trunk to 3.0 for new Spec work.  That way, we have a open 2.3 branch for any committer
updates against the current Spec level, while 2.2.x is a locked down branch like 2.1.x, 2.0.x,
1.0.x and 1.2.x.  If we polute 2.3 with future Spec work, then that complicates which JPA
TCK we have to pass before we can release that branch....



-Donald



________________________________
 From: Kevin Sutter <kwsutter@gmail.com>
To: dev@openjpa.apache.org; Mark Struberg <struberg@yahoo.de> 
Sent: Friday, January 6, 2012 11:02 AM
Subject: Re: [DISCUSS] release openjpa-2.2.0?
 
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
> >>>
> >>
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message