openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: merging to 1.0.x
Date Thu, 20 Sep 2007 14:26:43 GMT
That's the type of thing that would not hold me back from putting a
patch into a patch line, I think, if I thought the patch were
important enough. Which, clearly, I didn't in this case, since I
didn't merge it over in the first place.

BTW, I'm assuming that you've discovered the 'svn merge -c' syntax; it
makes moving changes from trunk to src pretty painless.

-Patrick

On 9/20/07, Michael Dick <michael.d.dick@gmail.com> wrote:
> 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
> >
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message