Re: svn commit: r670740 - in /openjpa/branches/wls-maintenance: ./ 1000mp1/

[Patrick Linskey]

If you can't just establish a "starting point" for your maintenance release

and use an existing branch, then I would suggest a branch name of

1.0.0.

0.9.7-r547073. At least we know it's somewhere beyond 0.9.7, but not quite

-Patrick

On Jun 27, 2008, at 11:51 AM, Kevin Sutter wrote:

Sounds good. Srinivasa: can you delete the branch that you created, and create a new one at /openjpa/branches/0.9.7-r547073? Moving forward, of course, it makes sense both for WebLogic (and other consumers) and for the OpenJPA community to strive to release off of actual published versions. FYI, it's currently our (Oracle's) intentions to do exactly that with the 1.1.0 release and the upcoming WebLogic 10.3 product.

Patrick and others,

On Fri, Jun 27, 2008 at 1:29 PM, Patrick Linskey <[EMAIL PROTECTED]> wrote:

Hi,

I guess I see things a bit differently than does Craig.

repository. Would that we all used git, my tune might be different.


repository, which directly damages the OpenJPA project and its goals.


what revision of OpenJPA they're running. This is possible because we

indirectly damages the OpenJPA project and its goals.

Pragmatically-speaking, it is quite difficult to "just" use an internal svn Setting up a separate svn repository for distribution-specific maintenance is a difficult proceeding, and is tantamount to a fork. Such a process would erect artificial barriers to pushing bugfixes back into the Apache OpenJPA Additionally, currently, a WebLogic Server end user can find out exactly (WebLogic) have worked hard to ensure that all our external releases are built directly from the public Apache svn repository. As soon as we start using an internal snapshot + changes of that repository, that transparency is eliminated, and a chunk of OpenJPA end users suffer along the way, which

released version of OpenJPA (ie. 1.0.0) or we have chosen a specific
SNAPSHOT revision number.  In either case, we have kept track of the


This "starting point" has always been somewhere in our existing branch
structure.  We currently have the following branches available in our
OpenJPA svn repository:

0.9.6-incubating
0.9.7-incubating
1.0.x
1.1.x

And, now we have a branch called wls-maintenance.  To expand on Mike's
earlier post, where does this "wls-maintenance" branch fit into the

how can we easily determine whether the fix affects any of the other
branches?  The point being is that we're not following our established
conventions for naming of branches and releases.


the door for ibm-maintenance, sun-maintenance, geronimo-maintenance,
bobs-maintanence, etc.


and use an existing branch, then I would suggest a branch name of

1.0.0.

Kevin

I agree with your concern here. We (IBM) have had the same concerns with internal repositories. That's why we have decided to build, package, and ship the binaries from the OpenJPA svn repository. As we have released various versions of WebSphere that supports OpenJPA, we have either used a specific svn revision so that we know the "starting point" for service. heirarchy? If someone commits a change to this "wls-maintenance" release, And, I don't want to clutter up our branches with lots and lots of confusing names. For example, if we start with this wls-maintenance, that would open If you can't just establish a "starting point" for your maintenance release 0.9.7-r547073. At least we know it's somewhere beyond 0.9.7, but not quite

I see this as different from, for example, an agreement by the OpenJPA

project to cut an early release, create a branch, and release a version (that happens to be used by a commercial product) and then maintain that

version.

I only see a temporal difference. Is there something else that I'm missing? There was no vote or other action by the project to establish the branch

objections (or comments of any sort) were raised.

and it's not a group of OpenJPA developers

I wasn't aware that branching was a vote-dependent action. Additionally, while there was no vote, there definitely was "other action". Srinivasa started a discussion on this topic a few months ago [1]. At the time, no

I don't understand what you're getting at here. To the best of my

the branch in question.

If asked to explain why we have branched the repository and are doing

knowledge, there are a group of OpenJPA contributors who intend to work on

maintenance on that branch, I'd have to say that it's solely for the support

of a commercial product.

One could also say "it is for ongoing support and hardening of a
widely-distributed packaging of OpenJPA".

-Patrick

[1] http://www.nabble.com/OpenJPA-branches-td16547180.html#a16547180


On Jun 26, 2008, at 5:01 PM, Craig L Russell wrote:

The biggest issue I have with the use of the Apache svn repository for

this purpose is that the repository tag was not created nor will it be used

to further the goals of the OpenJPA project.


stuff in the Apache svn repo.


version.


for maintenance.

Crag


On Jun 25, 2008, at 5:21 PM, Patrick Linskey wrote:

If asked to explain why we have branched the repository and are doing maintenance on that branch, I'd have to say that it's solely for the support of a commercial product. There was no vote or other action by the project to establish the branch and it's not a group of OpenJPA developers working on a sub-project that needs a branch. It's "just" a commercial entity with its I see this as different from, for example, an agreement by the OpenJPA project to cut an early release, create a branch, and release a version (that happens to be used by a commercial product) and then maintain that I'd suggest that for this purpose, BEA just use an internal svn repository So, going back to the original thread, one of the suggestions for naming

was:

http://svn.apache.org/repos/asf/openjpa/branches/r547073/


in his original email.

-Patrick

On Jun 25, 2008, at 2:55 PM, Michael Dick wrote:

Just my $0.02

It sounds like you'd prefer that approach. What about Craig and Kevin? I'm assuming that Srinivasa is ok with that approach, since he suggested it

from
time to time.


name

developer should I try to merge my patch from trunk to
wlsmaintenance/1000mp1?

Where it gets ugly is if the trend continued. Potentially creating
branches
for each consumer could cause a lot of confusion.

-mike


wrote:

I have no problems with 1. Posthumously creating a branch will happen I think that 2 can cause problems. It's not clear to me from the branch where wlsmaintenance fits. Is it before or after 1.1.0? If I'm a new On Wed, Jun 25, 2008 at 4:04 PM, Patrick Linskey <[EMAIL PROTECTED] > Personally, I don't see anything wrong with the approach taken so far.

It's

the

version).


(WebLogic), we hope to minimize the changes made to the branch to
important
bugfixes only, such that we can simply track that branch moving
forward. I

given



more
general sentiment are:

1. this branch was created post facto, rather than up-front

2. the name of the branch has vendor connotations


branch)
or issue 2 (a vendor name appearing in a branch)?

-Patrick


On Jun 25, 2008, at 1:16 PM, Michael Dick wrote:

definitely not the most ideal, but it seems to be a fair approach given situation (no branch was made at the time that WebLogic 10.0 shipped initially, and now there are changes that need to be made against that As discussed earlier, with the 1.1.x branch, which was driven by us expect that other organizations that push for a given release at a time to dovetail with their release trains will have similar desires. It seems like the only differences between the case at hand and that Are your objections to issue 1 (i.e., the existence of a post- facto I agree with Craig and Kevin. Vendor tags in the Apache SVN repository

should be avoided.


to

caused

before
similar changes went in.

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

checked

branch

name
of

might
have to do something to make OpenJPAVersion look correct to BEA
customers
though.


say

but
it
should fit the naming conventions we've laid out.

Regards,

-mike


On Wed, Jun 25, 2008 at 2:08 PM, Craig L Russell <
[EMAIL PROTECTED]>
wrote:

I'm also leery of adding another branch to maintain. Patrick alluded potentially dangerous changes which went into the 1.0.x branch which some concern for BEA. I'm guessing that rev 547073 is a point in time it, but it should fit in with the rest of our naming conventions. I out rev 547073 and pom.xml lists the version as 1.0.0- SNAPSHOT. Any made at this point would be between 0.9.7 and 1.0.0. I'd suggest a 0.9.x for the new branch. The poms should be rolled back and so on - Without looking at the differences between 547073 and 1.0.0 I can't whether we really need this branch. I am not opposed to creating one I agree with Kevin that we should eschew vendor tags in the OpenJPA

repository.


branch
a

you

1.1.x,
and 1.0.x branches as active code lines.


can do

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

update
into an Apache svn branch.

What do others think?

Craig


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


that I

It should be sufficient to have maintenance folks know from which maintenance release was cut (r547073, openjpa/trunk/ is really where shipped from??? After creating a 1.1.0 tag?). And we now have trunk, The only reason that I can think of to have a vendor tag is so you vendor maintenance in it. And I don't think we want to do that. If would be appropriate. And once the patch is verified to work, put the Wait a minute, Srinivasa. This doesn't seem right. I will admit didn't see your original posting asking for guidance, but I really

don't

specific
maintenance releases housed in the OpenJPA SVN repository.

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

just

would

incubation) instead of the the one WebLogic initially shipped.

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



approach
that you used.

Kevin

On Mon, Jun 23, 2008 at 3:36 PM, <[EMAIL PROTECTED]> wrote:

Author: ssegu

Date: Mon Jun 23 13:36:41 2008

think we want WebLogic, WebSphere, Geronimo, or any other vendor's the official 1.0.0 release. Is there some reason why you couldn't support your WebLogic customers using the 1.0.x service stream? It seem that customers would appreciate using an official release (post 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

New Revision: 670740

URL: http://svn.apache.org/viewvc?rev=670740&view=rev
Log:
Branched from revision that BEA WebLogic Server 10.0 MP1 was
released
from(rev #547073).

http://www.nabble.com/OpenJPA-branches-td16547180.html#a16547180

Added:
openjpa/branches/wls-maintenance/
openjpa/branches/wls-maintenance/1000mp1/
- copied from r547073, openjpa/trunk/



Craig Russell

Architect, Sun Java Enterprise System

http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



--

Patrick Linskey
202 669 5907

--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

--
Patrick Linskey
202 669 5907

--
Patrick Linskey
202 669 5907

smime.p7s
Description: S/MIME cryptographic signature