Hi Guys, Re the branching "lifecycle", I think that the life of a branch should be short, if possible branches should only be used to do one thing, ie add a feature, or re-implement a component, and try not to wander off into a myriad of different tweaks.
I'd like to see the Trunk be the latest (tested) working code, with branches used to develop features. Tags from Trunk to highlight stable releases of feature sets. possibly a BugFix Branch per feature-set Tag. I think that a naming convention for tags is a must, and that we should map branches and the features that they are adding in a "roadmap" document, so people can easily see what is being developed where. Also because subversion merging of branches is not straightforward (you need to know the version number when you branched, not just the head of your branch) then a published Merge procedure, and preferably a dedicated "merger" role, with people who have good experience at merging svn doing the merge to trunk. Also a full suite of relevant tests for each new feature should exist and pass before it is merged. That's my tuppence-worth Cheers Karl Frank Barnaby <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/12/2007 07:07 AM Please respond to [email protected] To [email protected] cc Subject Re: svn commit: r601098 - /incubator/river/trunk/jtsk/doc/release-notes/index.html First, let me say that I agree with David's suggestion that we should adhere to the established Subversion convention with a few minor modifications. However, Mark made a good point about needing to clarify the life-cycle with regard to branching and tagging releases. I have additional responses interspersed below. On Dec 5, 2007, at 08:17, Mark Brouwer wrote: > Hi David, > > Thanks for the response, IMHO Perforce is conceptually comparable to > Subversion but naming conventions probably differ and I agree we > should > follow the ones for Subversion, but as my knowledge with Subversion is > not beyond obtaining sources from it I hope others will translate the > concept in correct Subversion vocabulary. > > In the naming scheme you provided it is not completely clear yet where > you would work for the various stages, so let us give it a try with > the > given scenario. > > Say we are feature ready for version 3.0 of River and we want to > provide > support for 3.0 (bugfixes and maybe small features) while we are going > to work on version 3.1 as well. I would say we branch: > > /trunk 'branch into' /tags/release_3.0 > > After release 3.0 is really ready (stabilized) for an official > release we do: > > /tags/release_3.0 'branch into' /tags/release_3.0.0 I'd prefer to see the "tags" area remain a "golden", reference-only area for official releases to avoid mixing pre-release working copies with official releases in the same area. If we really need a pre-release working copy to allow newer work in the trunk, I'd suggest that we create a release-candidate branch in a separate, top-level, "release-candidates" directory. For those who may not be aware, Subversion does not have a labeling mechanism. Copies from specific repository revisions are used to create named (ie, "tagged") snapshots. Branches are also just copies. > All features for the next release (3.1) are developed in the /trunk or > some experimental or whatever branch. "Next release" work in the trunk seems reasonable. > But it turns out there are some > bugs in the 3.0.0 release. Fixing those bugs are conducted in the > /tags/release_3.0 until we believe we are really ready for the 3.0.1 > release. When ready we branch: > > /tags/release_3.0 'branch into' /tags/release_3.0.1 In the case of sustained work for previous releases, we could branch off of a tagged release, placing the working branch in a "sustaining" directory (eg, sustaining/release_3.0.1_work). When the sustained work is released, a tagged copy would be placed into the official "tags" area (eg, release_3.0.1). Obviously, changes in branches (sustaining work, prototype work, etc) that also apply to the latest work in the trunk or other sustaining work can be merged appropriately on an as needed basis regardless of where the working branches are located. The release candidates and sustaining branches could easily go into the "branches" area, but I suspect that area will quickly become cluttered with all sorts of stuff of varying importance. I'd prefer a few specific top-level folders. To summarize the above, we would have the following: /branches/ ## misc work /release-candidates/release_{ver}_candidate /sustaining/release_{ver}_work /trunk/ ## "latest" work /tags/release_{ver} ## only official releases Moving the "release-candidates" and "sustaining" dirs under "branches" would also be ok and would maintain the intent of a "branches" area. If we did this, I'd also make a "branches/misc" area to prevent the clutter I mentioned above. If we went with this option, the overall layout would look like: /branches/misc/ ## misc branched work /branches/release-candidates/release_{ver}_candidate/ /branches/sustaining/release_{ver}_work/ /trunk/ ## "latest" work /tags/release_{ver}/ ## only official releases Comments? Frank > And so on, and so on. If it turns out we are fixing bugs for 3.0.1 > that > are also a bug in the trunk we integrate the fixes from the > /tags/release_3.0 into the trunk: > > /tags/release_3.0 'integrate into' /trunk > > If it turns out that in the trunk we fixed a bug that needs to get > into > River 3.0 we integrate the relevant fixes from trunk into the > /tags/release_3.0 branch and from there in the 3.0.2 branch: > > /trunk 'integrate into' /tags/release_3.0 > /tags/release_3.0 'branch into' /tags/release_3.0.2 > > In the above I have no clue whether you should use the integration > features of Subversion or that you cherry-pick manually and just > apply the fixes to a certain branch. I know SVN doesn't track > integration history so with regard to a lot of integration work it > is pita anyway :-( > > David Parry wrote: > >> /tags/release_2.1 >> /tags/pre-release_2.1 >> /tags/release_2.1.1 >> ... >> where the second level is whatever naming scheme you find suitable. > > Personally I find it becoming crowded in the /tags branch (as I can > see > with many ASF projects) and not very expressive so I would opt for > introducing subdirectories to make a difference between a branch that > takes development and one that merely represents a 'label' of a > final release. > > If I didn't get something please correct me, I'm a virgin with good > SVN practices ... > -- > Mark > ----------------------------------------- This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.
