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 to1.0. When we're done with 1.0.0 we can create a new branch and tag with thecorrect 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 <[EMAIL PROTECTED]> wrote:On 8/24/07, Patrick Linskey <[EMAIL PROTECTED]> 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 backinto trunk. Can someone explain to me where we are going to do 1.0.1 work in thecurrent 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 pointwould 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 etcare branches off of 1.0 (I think). It seems like we should be able to accomplish that by renaming the 1.0.0branch to1.0. When we're done with 1.0.0 we can create a new branch and tag with thecorrect name. -Mike -PatrickOn 8/24/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:Kevin- Unless Patrick objects to the current (fourth) vote on the 1.0.0artifact based on this commit, it won't make it into the 1.0.0 finalrelease 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 additionsto 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 shouldprobably be a more solemn process, but since this is the first majorrelease 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 theone 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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} haverelations \ 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
