> 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 <[EMAIL PROTECTED]> 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/% > [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 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 <[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 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 <[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 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 <[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* > >>>>>> 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, [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} > >>>>>>>> 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
