On Aug 24, 2007, at 11:40 AM, Marc Prud'hommeaux 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 becausewe have not yet discussed a "1.0" roadmap.Let's put this bit to rest. I have been assuming per email discussionsfrom 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.xmaintenance. It is just a pathological special case in which there hasnot 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/[EMAIL PROTECTED] ).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 purposeis a Bad Idea. I see no reason why we should not just create a branchfor a release as described in my last two emails, rather than creatinga 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 commitchanges 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". Maintenancechanges 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.
I think the difference we're discussing is:1. Make a 1.0 branch and when it's ready, mark (tag) the bits that were approved. This means that the version number in the branch is 1.0.0 during the final days of the release, and after release we update the version number to be 1.0.1-SNAPSHOT.
2. Make a 1.0.0 branch and when it is ready, agree that it's read- only and copy the contents to 1.0 and update the version number inside the branch to 1.0.1-SNAPSHOT.
Question: What do we do when it's time to cut the 1.0.1 release? I've been assuming we'd be committing patches to the trunk and the 1.0.1 release manager will merge from trunk to 1.0 branch during the 1.0.1 release process. But the details of when to change the version number from 1.0.1-SNAPSHOT to 1.0.1 needs to be documented, and it might be clearer from that documentation how to continue.
I don't know of the specific case you're referring to where
"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."
This needs further discussion. Is this something we want to encourage? It implies that there are three active development code bases: 1.0.0, 1.0.1, and trunk.
It might be well to try to update the release process soon. Craig
-Patrick On 8/24/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> 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 becausewe have not yet discussed a "1.0" roadmap.I'm perfectly fine with making a "1.0" branch on which we will commitchanges 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". Maintenancechanges 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 thencreating another branch with allegedly-identical contents sounds errorprone 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 thenwork 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.1release, 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 bemaintenance work anyways. We just work on the release in the releasebranch, 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 havehardening 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 complicatesthe 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 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 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 -PatrickOn 8/24/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> 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* sourcecode 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 onthe 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 4thre-spin and [VOTE] was posted. So, does this require yet anotherrespin?If not, then what happens to these changes? The [VOTE] would notincludethese changes. So, would these changes automatically become partof 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.javaopenjpa/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}. Exceptionmessage: {1} \ No newline at end of file-- Patrick Linskey 202 669 5907-- Patrick Linskey 202 669 5907-- Patrick Linskey 202 669 5907
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
