> 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.