Mark,

Will it be fair to assume the following:
- Since your interest is to get 2.2.0 release out asap, you will be start
doing the 2.2.0 release work sometime this week.
- Once the release is complete we will assume the ownership of this
release, for service maintenance.

Thanks,
Albert Lee.

On Fri, Jan 6, 2012 at 4:08 PM, Mark Struberg <strub...@yahoo.de> wrote:

> Hi Albert!
> I have no special interrest in maintaining this branch longer as needed.
> I'm just a user like anyone else.
>
> The main reason for pushing this release is that the last OpenJPA release
> was pretty long time ago and trunk already contains quite a few important
> improvements.
>
> In OpenWebBeans and MyFaces we usually only create a new maintenance
> branch if there were big new features to be incorporated in trunk. If we
> know that we like to do a new heavyweight feature, then we create a branch
> for 2.2.x and do the maintenance there. Otherwise we release from trunk
> because we don't like to do all the merging stuff if not really needed.
>
> But I'm fine with whatever branching behaviour the OpenJPA community is
> used to (just need to know it).
>
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Albert Lee <allee8...@gmail.com>
> > To: dev@openjpa.apache.org
> > Cc:
> > Sent: Friday, January 6, 2012 6:41 PM
> > Subject: Re: [DISCUSS] release openjpa-2.2.0?
> >
> > 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 <kwsut...@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 <strub...@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 <strub...@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 <kwsut...@gmail.com>
> >>  > >>  To: dev@openjpa.apache.org; Donald Woods
> > <dwo...@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 <strub...@yahoo.de>
> >>  > >>>   To: openjpa-dev <dev@openjpa.apache.org>
> >>  > >>>   Cc: David Blevins <david.blev...@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.
> >
>



-- 
Albert Lee.

Reply via email to