openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
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 18:40:33 GMT

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


Mime
View raw message