openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: svn commit: r569253 - in /openjpa/branches/1.0.0/openjpa-kernel/src/main: java/org/apache/openjpa/enhance/PCEnhancer.java resources/org/apache/openjpa/enhance/localizer.properties
Date Fri, 24 Aug 2007 19:35:16 GMT
> The source isolation we lose is that if we have a "1.0" branch from
> which we directly cut release 1.0.0, and during the release process
> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
> then we don't have any way of differentiating or segregating those
> different types of changes. Note that this is not just a hypothetical
> concern: this actually was an issue in past releases on OpenJPA.

IIRC, this only happened in the past because we had a single line of
development. So sure, while cutting 0.9.6, changes that were targeted
for 0.9.7 were happening at the same time. But now that we will have a
release branch that is separate from trunk, I think that it is much
less likely for us to run into those situations. In fact, I think that
I would argue that it is usually undesirable to release a patch
release while another fix targeted at the same minor release is
halfway-implemented, as you've described.

> It almost sounds like you think I am intending to manually re-create
> the contents of the branch somewhere else, which isn't the case. I
> just intend to merge the "1.0.0" branch contents into either "trunk"
> to the potential "1.0" branch we've discussed. I simply don't

This is the first time that you have mentioned merging the 1.0.0
branch contents anywhere other than trunk. That is a good thing. I
believe that the extra branching is unnecessarily complex, but am
perfectly happy with a situation where the x.y.0 branch ends up
becoming the x.y branch post-release.

-Patrick

On 8/24/07, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
>
> On Aug 24, 2007, at 1:11 PM, Patrick Linskey wrote:
>
> >> "1.0.0". As we discussed before, we don't have a "1.0" branch because
> >> we have not yet discussed a "1.0" roadmap.
> >
> > Let's put this bit to rest. I have been assuming per email discussions
> > from last year and general best practices that we will have patch
> > releases that contain nothing but bugfixes. Given that, the 1.0.x
> > roadmap is by definition constrained to patches. A roadmap for 1.1
> > would be useful, but is totally separate from any need for a 1.0.x
> > branch.
>
> OK, that makes sense. I merely bring it up to point out that the
> scope of my branching activity was only ever designed to cover the
> current 1.0.0 release.
>
>
> >> The current "1.0.0" branch is *only* for changes that are to go into
> >> the 1.0.0 release. Full stop.
> >
> > ... and I think that this is unnecessary. I do not believe that the
> > concepts that you discussed are at all orthogonal to general 1.0.x
> > maintenance. It is just a pathological special case in which there has
> > not yet been a 1.0.0 release, but is otherwise identical to the
> > requirements for a 1.0.1 release or a 1.0.2 release.
>
> The issue of whether to have a short-term release-specific branch is,
> in fact, completely orthogonal to the issue of having long-term
> branches with release-targeted bugfixes and features.
>
> Nor is it pathological or in any way specific to OpenJPA version
> 1.0.0. One of the numerous reasons why we should have a release-
> specific branch is that we need a place where we commit the non "-
> SNAPSHOT" version number to the pom.xmls. If we were to do this on
> the trunk or on a long-term branch, then TeamCity or Continuum or
> some other CI system that is running off those branches will create
> release artifacts with the final "1.0.0" release number, a situation
> we want to avoid. This is one of the issues we discussed when Craig
> suggested this release branch strategy back in November (see http://
> mail-archives.apache.org/mod_mbox/openjpa-dev/200611.mbox/%
> 3c442CEE81-07D6-4067-9C74-96ADAD48FE82@SUN.com%3e ).
>
>
> >> It sounds like there is an *orthogonal* concern that we do not yet
> >> have a branch on which changes destined for 1.0.x should go. That's
> >> an understandable concern, but it has nothing to do with the very
> >> specific and short-lived purpose of the branch that is called
> >> "1.0.0".
> >
> > I think that having a branch for this specific and short-lived purpose
> > is a Bad Idea. I see no reason why we should not just create a branch
> > for a release as described in my last two emails, rather than creating
> > a branch, throwing it away, and hopefully properly re-creating a
> > branch with the same contents.
>
> It almost sounds like you think I am intending to manually re-create
> the contents of the branch somewhere else, which isn't the case. I
> just intend to merge the "1.0.0" branch contents into either "trunk"
> to the potential "1.0" branch we've discussed. I simply don't
> understand why you think this is a Bad Idea. Maybe if you posted some
> concrete examples of the specific pitfalls you predict, then we would
> be able to better understand your objections.
>
>
> >> I'm perfectly fine with making a "1.0" branch on which we will commit
> >> changes destined for 1.0.x releases. Ideally, this would have been
> >> done before we branched for "1.0.0", so that we could have branched
> >> from the "1.0" branch, but I don't know if subversion actually cares
> >> about the hierarchy of branches when it comes to merging.
> >
> > Indeed, I think that ideally, it should have been done *instead* of
> > creating the "1.0.0" branch.
> >
> >> So how about we do the following?
> >>
> >> 1. Immediately create a branch off of trunk called "1.0". Maintenance
> >> changes destined for 1.0.1 will be made on that branch.
> >> 2. Once the 1.0.0 release is approved and published, merge the
> >> changes from the "1.0.0" branch into the "1.0" branch and tag the
> >> released bits in the "1.0.0" branch as "1.0.0", then delete the
> >> "1.0.0" branch.
> >> 3. In the future, cut the "1.0.1" branch off of the "1.0" branch.
> >
> > I think that we should do the following:
> >
> > 1. rename the "1.0.0" branch to "1.0". Maintenance changes destined
> > fro 1.0.1 will be made on that branch.
>
> I will do this once the release is approved and published.
>
> > 2. Once the 1.0.0 release is approved and published, create a 1.0.0
> > tag, and do not delete the 1.0 branch.
>
> I will do that (probably before #1, since one or two things have been
> already committed to the 1.0.0 branch after the latest artifact was
> uploaded for voting).
>
> > 3. In the future, do not cut a "1.0.1" branch at all. Instead, when
> > the time comes for 1.0.1 work, do it directly from the 1.0 branch
> > (which, per my assertion above, contains only bugfixes, and so does
> > not risk tainting the branch), and create a tag from the branch.
> >
> > I think that this simplifies and streamlines the process, and loses
> > none of the current source-isolation that we have in our
> > transient-branch strategy.
>
> The source isolation we lose is that if we have a "1.0" branch from
> which we directly cut release 1.0.0, and during the release process
> Developer A commits a typo fix to LICENSE.txt they want in 1.0.0, and
> Developer B fixes a semi-tested bugfix they don't want until 1.0.1,
> then we don't have any way of differentiating or segregating those
> different types of changes. Note that this is not just a hypothetical
> concern: this actually was an issue in past releases on OpenJPA.
>
> In conclusion, the crux of the disagreement seems simply to be: do we
> want a transient release-specific branch or not. I think we do, for
> the reasons listed above. You appear to deem it sufficient to have
> only a long-lived parent branch from which we directly cut the
> release. It's a fairly minor issue, but one I expect we will want to
> discuss more and vote on before the the next release.
>
>
>
> > -Patrick
> >
> > On 8/24/07, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
> >>
> >> I think the point of having a release branch is so that:
> >>
> >> 1. Cosmetic/miscellaneous changes can be made in the release branch
> >> to fix problems with the candidate builds.
> >> 2. More importantly, other people can make changes on one of the
> >> parent branch(es) during the sometimes multi-week release voting
> >> process without messing up the release branch.
> >>
> >> The current "1.0.0" branch is *only* for changes that are to go into
> >> the 1.0.0 release. Full stop.
> >>
> >> It sounds like there is an *orthogonal* concern that we do not yet
> >> have a branch on which changes destined for 1.0.x should go. That's
> >> an understandable concern, but it has nothing to do with the very
> >> specific and short-lived purpose of the branch that is called
> >> "1.0.0". As we discussed before, we don't have a "1.0" branch because
> >> we have not yet discussed a "1.0" roadmap.
> >>
> >> I'm perfectly fine with making a "1.0" branch on which we will commit
> >> changes destined for 1.0.x releases. Ideally, this would have been
> >> done before we branched for "1.0.0", so that we could have branched
> >> from the "1.0" branch, but I don't know if subversion actually cares
> >> about the hierarchy of branches when it comes to merging.
> >>
> >> So how about we do the following?
> >>
> >> 1. Immediately create a branch off of trunk called "1.0". Maintenance
> >> changes destined for 1.0.1 will be made on that branch.
> >> 2. Once the 1.0.0 release is approved and published, merge the
> >> changes from the "1.0.0" branch into the "1.0" branch and tag the
> >> released bits in the "1.0.0" branch as "1.0.0", then delete the
> >> "1.0.0" branch.
> >> 3. In the future, cut the "1.0.1" branch off of the "1.0" branch.
> >>
> >>
> >>
> >>
> >> On Aug 24, 2007, at 12:23 PM, Patrick Linskey wrote:
> >>
> >>>> It seems like we should be able to accomplish that by renaming the
> >>>> 1.0.0branch to
> >>>> 1.0. When we're done with 1.0.0 we can create a new branch and tag
> >>>> with the
> >>>> correct name.
> >>>
> >>> I agree completely.
> >>>
> >>> I think that making the branch and then throwing it away and then
> >>> creating another branch with allegedly-identical contents sounds
> >>> error
> >>> prone and cumbersome.
> >>>
> >>> As I mentioned earlier, I think that we should change our
> >>> processes to
> >>> create a release branch for an x.y.0 release from wherever it is
> >>> that
> >>> that branch is being sourced (trunk, somewhere else, etc.), and then
> >>> work on a release on that branch. Once the release is done, we then
> >>> tag that moment in time, but keep the x.y release branch alive for
> >>> work that should go into x.y.1. When the time comes for the x.y.1
> >>> release, we then do not need to create one of these release
> >>> branches,
> >>> since the only work that's happening in the x.y branch should be
> >>> maintenance work anyways. We just work on the release in the release
> >>> branch, get it done, and then tag it when it's ready.
> >>>
> >>> I think that our current model of making these transient branches is
> >>> well-suited for a single-branch methodology. That worked well
> >>> while we
> >>> were working towards a 1.0.0 release, since we never planned to have
> >>> hardening releases off of 0.9.7, for example. But now that we're
> >>> moving past 1.0.0, I think that it's important to have a branching
> >>> strategy in place that supports patch line maintenance.
> >>>
> >>> Thoughts?
> >>>
> >>> -Patrick
> >>>
> >>> On 8/24/07, Michael Dick <michael.d.dick@gmail.com> wrote:
> >>>> On 8/24/07, Patrick Linskey <plinskey@gmail.com> wrote:
> >>>>>
> >>>>> I agree with most of what Marc is saying. However, I strongly feel
> >>>>> that we need to change how we're doing our branching strategy.
> >>>>> In my
> >>>>> opinion, creating these throwaway branches unnecessarily
> >>>>> complicates
> >>>>> the process of making a maintenance branch for a given release.
> >>>>
> >>>>
> >>>> +1. Marc (or any other release manager) shouldn't have to merge
> >>>> changes back
> >>>> into trunk.
> >>>>
> >>>> Can someone explain to me where we are going to do 1.0.1 work in
> >>>> the
> >>>>> current process?
> >>>>
> >>>>
> >>>> Prior to our discussion in a different thread I thought that 1.0.1
> >>>> work
> >>>> would be done in the 1.0.0 branch that we're using now. Basically
> >>>> when we're
> >>>> done with 1.0.0 we would create a tag. Anything committed after
> >>>> that point
> >>>> would be part of 1.0.1 until we release it and create another tag.
> >>>>
> >>>> The new plan is to create a branch and call it 1.0. 1.0.0, 1.0.1,
> >>>> 1.0.2 etc
> >>>> are branches off of 1.0 (I think).
> >>>>
> >>>> It seems like we should be able to accomplish that by renaming the
> >>>> 1.0.0branch to
> >>>> 1.0. When we're done with 1.0.0 we can create a new branch and tag
> >>>> with the
> >>>> correct name.
> >>>>
> >>>> -Mike
> >>>>
> >>>> -Patrick
> >>>>>
> >>>>> On 8/24/07, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
> >>>>>> Kevin-
> >>>>>>
> >>>>>> Unless Patrick objects to the current (fourth) vote on the 1.0.0
> >>>>>> artifact based on this commit, it won't make it into the 1.0.0
> >>>>>> final
> >>>>>> release bits.
> >>>>>>
> >>>>>> Once 1.0.0 is released, I will tag the currently *released*
> >>>>>> source
> >>>>>> code in the 1.0.0 branch as "1.0.0", and then merge the *latest*
> >>>>>> source code in the 1.0.0 branch back into the trunk, so any
> >>>>>> additions
> >>>>>> to the 1.0.0 branch will certainly be merged back to the trunk
> >>>>>> (although they will only be released in the 1.0.0 assembly if
we
> >>>>>> happen to need to cut another release).
> >>>>>>
> >>>>>> I will document this process on the revised release
> >>>>>> instructions on
> >>>>>> the wiki once I get around to assembling them. We are playing
a
> >>>>>> little fast and loose with last-minute changes in what should
> >>>>>> probably be a more solemn process, but since this is the first
> >>>>>> major
> >>>>>> release as a TLP, I think we can make a few exceptions.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Aug 24, 2007, at 8:37 AM, Kevin Sutter wrote:
> >>>>>>
> >>>>>>> Patrick and Marc,
> >>>>>>> Help me understand our process here.  This commit is similar
to
> >>>>>>> the
> >>>>>>> one I
> >>>>>>> did the other evening.  It was committed into the 1.0.0
branch
> >>>>>>> after the 4th
> >>>>>>> re-spin and [VOTE] was posted.  So, does this require yet
> >>>>>>> another
> >>>>>>> respin?
> >>>>>>> If not, then what happens to these changes?  The [VOTE]
would
> >>>>>>> not
> >>>>>>> include
> >>>>>>> these changes.  So, would these changes automatically become
> >>>>>>> part
> >>>>>>> of the
> >>>>>>> 1.0.1 snapshot release?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Kevin
> >>>>>>>
> >>>>>>> On 8/24/07, pcl@apache.org <pcl@apache.org> wrote:
> >>>>>>>>
> >>>>>>>> Author: pcl
> >>>>>>>> Date: Thu Aug 23 22:27:43 2007
> >>>>>>>> New Revision: 569253
> >>>>>>>>
> >>>>>>>> URL: http://svn.apache.org/viewvc?rev=569253&view=rev
> >>>>>>>> Log:
> >>>>>>>> Minor logging / exception handling improvements
> >>>>>>>>
> >>>>>>>> Modified:
> >>>>>>>>
> >>>>>>>>     openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/
> >>>>>>>> apache/
> >>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>>     openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/
> >>>>>>>> org/
> >>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Modified:
> >>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
> >>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>> URL:
> >>>>>>>> http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-
> >>>>>>>> kernel/
> >>>>>>>> src/main/java/org/apache/openjpa/enhance/PCEnhancer.java?
> >>>>>>>> rev=569253&r1=569252&r2=569253&view=diff
> >>>>>>>> ===============================================================
> >>>>>>>> ==
> >>>>>>>> ====
> >>>>>>>> =========
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
> >>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>> (original)
> >>>>>>>> +++
> >>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/java/org/apache/
> >>>>>>>> openjpa/enhance/PCEnhancer.java
> >>>>>>>> Thu Aug 23 22:27:43 2007
> >>>>>>>> @@ -467,7 +467,8 @@
> >>>>>>>>          } catch (OpenJPAException ke) {
> >>>>>>>>              throw ke;
> >>>>>>>>          } catch (Exception e) {
> >>>>>>>> -            throw new GeneralException(e);
> >>>>>>>> +            throw new GeneralException(_loc.get("enhance-
> >>>>>>>> error",
> >>>>>>>> +                _managedType.getType().getName(), e.getMessage
> >>>>>>>> ()), e);
> >>>>>>>>          }
> >>>>>>>>      }
> >>>>>>>>
> >>>>>>>> @@ -2736,7 +2737,10 @@
> >>>>>>>>              } catch (Throwable t) {
> >>>>>>>>                  // last-chance catch for bug #283 (which
can
> >>>>>>>> happen
> >>>>>>>>                  // in a variety of ClassLoading environments)
> >>>>>>>> -                _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>> _meta), t);
> >>>>>>>> +                if (_log.isTraceEnabled())
> >>>>>>>> +                    _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>> _meta), t);
> >>>>>>>> +                else
> >>>>>>>> +                    _log.warn(_loc.get("enhance-uid-access",
> >>>>>>>> _meta));
> >>>>>>>>              }
> >>>>>>>>
> >>>>>>>>              // if we couldn't access the serialVersionUID,
we
> >>>>>>>> will have
> >>>>>>>> to
> >>>>>>>> @@ -3672,10 +3676,13 @@
> >>>>>>>>       * attribute name for the backing field <code>name</code>.
> >>>>>>>>       */
> >>>>>>>>      private String fromBackingFieldName(String name)
{
> >>>>>>>> -        if (_meta.getAccessType() ==
> >>>>>>>> ClassMetaData.ACCESS_PROPERTY
> >>>>>>>> +        // meta is null when doing persistence-aware
> >>>>>>>> enhancement
> >>>>>>>> +        if (_meta != null
> >>>>>>>> +            && _meta.getAccessType() ==
> >>>>>>>> ClassMetaData.ACCESS_PROPERTY
> >>>>>>>>              && _fieldsToAttrs.containsKey(name))
> >>>>>>>> -            name = (String) _fieldsToAttrs.get(name);
> >>>>>>>> -        return name;
> >>>>>>>> +            return (String) _fieldsToAttrs.get(name);
> >>>>>>>> +        else
> >>>>>>>> +            return name;
> >>>>>>>>      }
> >>>>>>>>
> >>>>>>>>      /**
> >>>>>>>>
> >>>>>>>> Modified:
> >>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>> URL:
> >>>>>>>> http://svn.apache.org/viewvc/openjpa/branches/1.0.0/openjpa-
> >>>>>>>> kernel/
> >>>>>>>> src/main/resources/org/apache/openjpa/enhance/
> >>>>>>>> localizer.properties?
> >>>>>>>> rev=569253&r1=569252&r2=569253&view=diff
> >>>>>>>> ===============================================================
> >>>>>>>> ==
> >>>>>>>> ====
> >>>>>>>> =========
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>> (original)
> >>>>>>>> +++
> >>>>>>>> openjpa/branches/1.0.0/openjpa-kernel/src/main/resources/org/
> >>>>>>>> apache/openjpa/enhance/localizer.properties
> >>>>>>>> Thu Aug 23 22:27:43 2007
> >>>>>>>> @@ -197,4 +197,5 @@
> >>>>>>>> no-accessor: Could not find method called {0} in type
{1}.
> >>>>>>>> unspecified-unenhanced-types: One or more of the types
in {0}
> >>>>>>>> have
> >>>>>>>> relations \
> >>>>>>>>      to other unenhanced types that were not specified.
These
> >>>>>>>> unspecified
> >>>>>>>> types \
> >>>>>>>> -    are: {1}
> >>>>>>>> \ No newline at end of file
> >>>>>>>> +    are: {1}
> >>>>>>>> +enhance-error: An error occurred while enhancing {0}.
> >>>>>>>> Exception
> >>>>>>>> message:
> >>>>>>>> {1}
> >>>>>>>> \ No newline at end of file
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Patrick Linskey
> >>>>> 202 669 5907
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Patrick Linskey
> >>> 202 669 5907
> >>
> >>
> >
> >
> > --
> > Patrick Linskey
> > 202 669 5907
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message