I'm not sure the Select interface is entirely internal. It's not a user facing API by any means, but if you're extending the OpenJPA provider, you might need to use the interface.
If a third party persistence provider has a custom SQLFactory class they might also have a custom SelectImpl. If the custom SelectImpl doesn't extend our classes then they'll have to update their code to account for the new method. There are a lot of ifs here, and I'm not aware of anyone that fits my scenario. Maybe it's a corner case though. -Mike On 9/20/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > Actually on further inspection I think I messed up when I merged > > OPENJPA-356. I didn't notice that I updated the Select interface which > > shouldn't be done on a maintenance release. I checked with Kevin and he > > agreed, so I've backed out the change. Sorry for making a mess in svn. > > I'd say that that's definitely a fair change. It's just an added > method, which won't cause any compile problems. Additionally, that > class is very much an internal part of OpenJPA; what level of > compatibility within a patch release do we want to guarantee for > internals? > > Ideally, it seems like it'd be nice to keep our API stable pretty much > forever, and then have some internal SPIs that have a lower level of > compatibility promises. > > -Patrick > > On 9/19/07, Michael Dick <[EMAIL PROTECTED]> wrote: > > Actually on further inspection I think I messed up when I merged > > OPENJPA-356. I didn't notice that I updated the Select interface which > > shouldn't be done on a maintenance release. I checked with Kevin and he > > agreed, so I've backed out the change. Sorry for making a mess in svn. > > > > General comments below (for what they're worth) > > > > On 9/19/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > > > I don't think that you are misinterpreting it. Also, I don't think > > > that we've done anything that's bad yet; I just thought it'd be good > > > to discuss to make sure we're all on the same page. > > > > > > Personally, I do not much like the idea of porting all of my changes > > > to multiple branches every time I change something. That definitely > > > discourages me from making fixes. > > > > > > Perfectly fine by me. Any bug fixes should be fair game to be merged > later > > though. Conversations like this will come up if any of us get over > zealous > > and move something they shouldn't have > > > > During the release process, we decided that it was not the > > > responsibility of the release builder to merge changes made in an > > > x.y.z branch back to the trunk. I think that where we arrived was that > > > it should instead be the responsibility of the developers to get the > > > code to wherever they deemed it belonged, under the assumption that > > > the x.y.z branches would never pick up changes or merge back down in a > > > bulk / automated manner. > > > > > > > For example, I've made some fixes that I thought were important enough > > > to do the svn merge to the branch, and I've made some that I didn't > > > think were really that important. You may have subsequently moved some > > > of those to the branch (I haven't checked that closely); that's great, > > > since presumably you thought that the changes were important enough to > > > spend the time on. > > > > > > To sum up, I think it's important that we not destabilize the > > > branches, but other than that, we should feel free, but not obligated, > > > to put fixes into trunk and relevant branches. But we must remember > > > that there is no process in place to move changes only made in a > > > branch back to the trunk. > > > > > > I think I agree. The main point here is that there's no automatic > merging > > going on. It's up to individual committers to put their fixes in the > > appropriate branches etc. > > > > > > -Patrick > > > > > > On 9/19/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > > > Hi Patrick, > > > > It seemed like a lot of "fixes" were going into the 1.1.0 release > and > > > not > > > > making it back into the 1.0.x release. Since it seemed like it > might be > > > a > > > > while before we develop enough new feature content to warrant a bump > > > from > > > > 1.0.0 to 1.1.0, I think it would be worthwhile to keep 1.0.xup-to-date > > > as > > > > far as fixes are concerned. I had done a quick JIRA query and found > > > that we > > > > had close to a dozen fixes in the 1.1.0 release that had not made it > > > back to > > > > the 1.0.x release. Reading through the JIRA reports, the problems > > > sounded > > > > like plain old defects and not new features. I started to move some > of > > > the > > > > changes back to the 1.0.x release and then Mike started to help out. > > > > > > > > So, from a release maintenance viewpoint, I would like us to be more > > > > diligent with ensuring that defect fixes make it back into the > current > > > > maintenance release (as well as trunk). Of course, there may be > reasons > > > why > > > > this may not make sense due to the extent of the changes, but so far > the > > > > changes have been pretty minimal. The most extensive change is with > the > > > > Java 2 security changes at this point. > > > > > > > > If I am misinterpreting the x.y.z release conventions, then let's > > > discuss > > > > that. > > > > > > > > Thanks, > > > > Kevin > > > > > > > > On 9/18/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi, > > > > > > > > > > It seems like we've had a lot of activity merging things to the > 1.0.x > > > > > branch. Personally, it seems like there's maybe even too much > stuff > > > > > going into there; what is our plan for QA for the changes in the > 1.0.1 > > > > > release at this point? > > > > > > > > > > Also, a lot of the @since tags are now wrong, since they were > written > > > > > with 1.1.0 in mind, but now the changes are slated for 1.0.1. > > > > > > > > > > Thoughts? > > > > > > > > > > -Patrick > > > > > > > > > > -- > > > > > Patrick Linskey > > > > > 202 669 5907 > > > > > > > > > > > > > > > > > > -- > > > Patrick Linskey > > > 202 669 5907 > > > > > > > > -- > Patrick Linskey > 202 669 5907 >
