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 09:06:55 GMT
> 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.x up-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
View raw message