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 03:29:09 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.

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
>

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