Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <20866438.1193154351475.JavaMail.jira@brutus>
Date: Tue, 23 Oct 2007 08:45:51 -0700 (PDT)
From: "Patrick Linskey (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Commented: (OPENJPA-404) Backward-compatibility for pre-1.0
 APIs
In-Reply-To: <9396673.1192552850568.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537047 ] 

Patrick Linskey commented on OPENJPA-404:
-----------------------------------------

> It might inform this discussion to understand what BEA policy has to
> say about fixing backward compatibility issues.

The next WebLogic release will ship with something cut from what is currently in trunk, so we (BEA) have no need for this to be in 1.0.x.

> Personally, I have no issue with this particular issue being fixed only
> in 1.1.x but it might be good to have OpenJPA policy in sync with BEA policy...

First, it's important to note that this problem is a special case, since OpenJPA went from pre-release (0.9.7) to release (1.0), and so we (OpenJPA) were in the initial state condition.

I believe that it will be difficult in general to come up with a hard and fast policy for deprecation OpenJPA that is guaranteed to be compatible with BEA's policy. IIRC, BEA guarantees that a given API won't disappear within two major releases. Since the WebLogic release cycle is different than the OpenJPA release cycle, we can't write an OpenJPA policy that will guarantee that trunk is backward-compatible with whatever BEA released two release cycles earlier. (Well, unless we encoded a dependency on WebLogic release cycles in the OpenJPA policy, which seems like a bad idea.)

I think that this is OK. If OpenJPA decides to break APIs in the future (presumably per our compatibility policy), then BEA may need to release off of an old line for some period of time. This is understood at BEA, and is just one of those things.

Note that one of the goals of solidifying our APIs was to constrain things so that it's easy for people like us at BEA to reference a stable bounded set of OpenJPA APIs. So, I'm hopeful that post-1.0 (i.e., now), we will be in a safer position moving forward.

> Backward-compatibility for pre-1.0 APIs
> ---------------------------------------
>
>                 Key: OPENJPA-404
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-404
>             Project: OpenJPA
>          Issue Type: New Feature
>    Affects Versions: 1.0.0
>            Reporter: Patrick Linskey
>             Fix For: 1.1.0
>
>         Attachments: OPENJPA-404.patch
>
>
> When I changed the OpenJPA APIs before the 1.0 release, I made a number of incompatible changes. At the time, we deemed that this was fine since 1.0 was the first OpenJPA release. However, it turns out that this runs up against BEA policy, since BEA shipped a product using a build from around 0.9.7. So, we'd like to do some work to address this where possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.