openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srinivasa Segu" <>
Subject RE: svn commit: r670740 - in /openjpa/branches/wls-maintenance: ./ 1000mp1/
Date Wed, 25 Jun 2008 20:42:04 GMT
I am definitely open to changing the name of the branch to conform to the conventions. As far
as the intent in creating the branch - it was to start-off from the revision of OpenJPA that
was used for a Weblogic release, and only include vital non-intrusive changes that would help
in maintenance releases.


-----Original Message-----
From: Michael Dick [] 
Sent: Wednesday, June 25, 2008 1:16 PM
Subject: Re: svn commit: r670740 - in /openjpa/branches/wls-maintenance: ./ 1000mp1/


I agree with Craig and Kevin. Vendor tags in the Apache SVN repository

should be avoided.


I'm also leery of adding another branch to maintain. Patrick alluded to

potentially dangerous changes which went into the 1.0.x branch which caused

some concern for BEA. I'm guessing that rev 547073 is a point in time before

similar changes went in.


If that's the motivation for creating a branch I'm not entirely opposed to

it, but it should fit in with the rest of our naming conventions. I checked

out rev 547073 and pom.xml lists the version as 1.0.0-SNAPSHOT. Any branch

made at this point would be between 0.9.7 and 1.0.0. I'd suggest a name of

0.9.x for the new branch. The poms should be rolled back and so on - might

have to do something to make OpenJPAVersion look correct to BEA customers



Without looking at the differences between 547073 and 1.0.0 I can't say

whether we really need this branch. I am not opposed to creating one but it

should fit the naming conventions we've laid out.







On Wed, Jun 25, 2008 at 2:08 PM, Craig L Russell <>



> I agree with Kevin that we should eschew vendor tags in the OpenJPA

> repository.


> It should be sufficient to have maintenance folks know from which branch a

> maintenance release was cut (r547073, openjpa/trunk/ is really where you

> shipped from??? After creating a 1.1.0 tag?). And we now have trunk, 1.1.x,

> and 1.0.x branches as active code lines.


> The only reason that I can think of to have a vendor tag is so you can do

> vendor maintenance in it. And I don't think we want to do that. If you need

> to make patches for specific customers, it seems that a local repository

> would be appropriate. And once the patch is verified to work, put the update

> into an Apache svn branch.


> What do others think?


> Craig



> On Jun 23, 2008, at 2:36 PM, Kevin Sutter wrote:


>  Wait a minute, Srinivasa.  This doesn't seem right.  I will admit that I

>> didn't see your original posting asking for guidance, but I really don't

>> think we want WebLogic, WebSphere, Geronimo, or any other vendor's

>> specific

>> maintenance releases housed in the OpenJPA SVN repository.


>> It looks like WebLogic shipped something between the 0.9.7-incubating and

>> the official 1.0.0 release.  Is there some reason why you couldn't just

>> support your WebLogic customers using the 1.0.x service stream?  It would

>> seem that customers would appreciate using an official release (post

>> incubation) instead of the the one WebLogic initially shipped.


>> Do you need a complete branch?  Or, are you just interested in tagging the

>> branch so that you can easily find the start of your service stream?


>> I think we need to do something different here.  I don't like the approach

>> that you used.


>> Kevin


>> On Mon, Jun 23, 2008 at 3:36 PM, <> wrote:


>>  Author: ssegu

>>> Date: Mon Jun 23 13:36:41 2008

>>> New Revision: 670740


>>> URL:

>>> Log:

>>> Branched from revision that BEA WebLogic Server 10.0 MP1 was released

>>> from(rev #547073).




>>> Added:

>>>  openjpa/branches/wls-maintenance/

>>>  openjpa/branches/wls-maintenance/1000mp1/

>>>    - copied from r547073, openjpa/trunk/




> Craig Russell

> Architect, Sun Java Enterprise System

> 408 276-5638

> P.S. A good JDO? O, Gasp!




Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.


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