openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: merging to 1.0.x
Date Thu, 20 Sep 2007 14:06:13 GMT
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 <plinskey@gmail.com> 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 <michael.d.dick@gmail.com> 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 <plinskey@gmail.com> 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 <kwsutter@gmail.com> 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 <plinskey@gmail.com> 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
>

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