development/maintenance/R0_7_maintenance.xml - www.eclipse.org/webtools - Git at Google

 <?xml-stylesheet type="text/xsl" href="../../wtphome.xsl"?>
 <html>
 <head>
   <title>Web Tools Platform 0.7 maintenance stream proposal</title>
   <meta name="root" content="../../.." />
 </head>
 <body>

 <h1>WTP 0.7 maintenance stream proposal</h1>
 <p align="right"><em>Updated 2005-08-03</em></p>

 <h2>Introduction</h2>

 <p>
 Branch name: <b>R0_7_maintenance</b>
 </p>

 <p>
 The process described in this document follows the maintenance release process used by the
 Eclipse platform project. This process requires us to branch all the build related project.
 In WTP, that would be the <b>releng</b> and the <b>releng.builder</b> project. Unlike the build
 projects, plug-in projects and feature projects will be branched on demand, meaning we need to
 branch them when a fixed is needed in the maintenance stream.
 </p>

 <p>
 There will not be any "HEAD" build for the maintenance stream. That means a maintenance build will
 always be built from the branched map files. The advantage for this approach is that we don't need
 to branch everything. If we want to do "HEAD" builds in the maintenance stream, then all plug-ins/features need
 to be branched regardless of whether changes are made to them or not. To keep things simple, let's
 stay away from "HEAD" builds. This means, you need to release all your changes before they would
 actually show up in a maintenance build. Releasing changes to the maintenance stream is the same
 as releasing changes to the 1.0 stream. The only difference is that you MUST release to the branched
 map files, not the HEAD map files.
 </p>

 <h2>Creating a branch for a plug-in/feature</h2>

 <p>
 Creating a branch for a plug-in/feature is fairly easy, here's a laundry list of what needs to be done:
 <ol>
 <li>Check out the plug-in/feature project that you want to branch.</li>
 <li>Right click on the project > Team > Branch...</li>
 <li>Enter <b>R0_7_maintenance</b> as the branch name > OK.</li>
 <li>That's it. You have successfully created a branch. The following figures show you the
 difference between a HEAD branch project and a 0.7 maintenance branch project.</li>
 </ol>
 </p>
 <p>
 <img src="figure1.gif"/>
 <img src="figure2.gif"/>
 </p>

 <h2>Checking out from a branch</h2>

 <p>
 To check out from a branch:
 <ol>
 <li>Create a CVS location just like you normally would.</li>
 <li>Expand the HEAD branch, and right click on the project that you want to work with > Configure Branches and Versions...</li>
 <li>A dialog opens. In the <b>Browse files for tags</b> section of this dialog (top left region), select any file that has
 been branched. For example (I branched the <b>component-api.xsd</b> file for testing purposes)
 <br/><img src="figure3.gif"/>
 </li>
 <li>Once you have selected the file, the <b>New tags found in the selected files</b> section (top right region) should be
 updated with the 0.7 maintenance branch name. Make sure only the <b>R0_7_Maintenance</b> branch is checked.</li>
 <li>Click on the <b>Add Checked Tags</b> button.</li>
 <li>Click <b>OK</b>.</li>
 <li>A new branch should be created in your CVS location. You can check out and commit to branch just like the HEAD branch.
 <br/><img src="figure4.gif"/>
 </li>
 </ol>
 </p>

 <p>
 For changes that need to go into both the HEAD and 0.7 branch, I find that retrofitting/merging changes manually is the easiest.
 Since our 0.7 branch is limited to critical and NL fixes only, there shouldn't be too much work. However, if you like the Eclipse
 CVS tools, they do come with some merging tool that you can use. It helps you merge 0.7 branch change back into HEAD.
 This <a href="http://www.eclipse.org/articles/Article-CVS-branching/eclipse_branch.html">article</a> talks about this tool.
 </p>

 <h2>Tracking 0.7 maintenance fixes in bugzilla</h2>

 <p>
 We now have a <b>1.0 M7.1</b> target in bugzilla. I suggest when a fix is retrofitted from the 1.0 stream
 to the 0.7 maintenance stream, we change the target of the corresponding bug to <b>1.0 M7.1</b>.
 We can then create a bugzilla query to see what fixes went into the maintenance stream.
 </p>

 </body>
 </html>
	<?xml-stylesheet type="text/xsl" href="../../wtphome.xsl"?>
	<html>
	<head>
	<title>Web Tools Platform 0.7 maintenance stream proposal</title>
	<meta name="root" content="../../.." />
	</head>
	<body>

	<h1>WTP 0.7 maintenance stream proposal</h1>
	<p align="right"><em>Updated 2005-08-03</em></p>

	<h2>Introduction</h2>

	<p>
	Branch name: <b>R0_7_maintenance</b>
	</p>

	<p>
	The process described in this document follows the maintenance release process used by the
	Eclipse platform project. This process requires us to branch all the build related project.
	In WTP, that would be the <b>releng</b> and the <b>releng.builder</b> project. Unlike the build
	projects, plug-in projects and feature projects will be branched on demand, meaning we need to
	branch them when a fixed is needed in the maintenance stream.
	</p>

	<p>
	There will not be any "HEAD" build for the maintenance stream. That means a maintenance build will
	always be built from the branched map files. The advantage for this approach is that we don't need
	to branch everything. If we want to do "HEAD" builds in the maintenance stream, then all plug-ins/features need
	to be branched regardless of whether changes are made to them or not. To keep things simple, let's
	stay away from "HEAD" builds. This means, you need to release all your changes before they would
	actually show up in a maintenance build. Releasing changes to the maintenance stream is the same
	as releasing changes to the 1.0 stream. The only difference is that you MUST release to the branched
	map files, not the HEAD map files.
	</p>

	<h2>Creating a branch for a plug-in/feature</h2>

	<p>
	Creating a branch for a plug-in/feature is fairly easy, here's a laundry list of what needs to be done:
	<ol>
	<li>Check out the plug-in/feature project that you want to branch.</li>
	<li>Right click on the project > Team > Branch...</li>
	<li>Enter <b>R0_7_maintenance</b> as the branch name > OK.</li>
	<li>That's it. You have successfully created a branch. The following figures show you the
	difference between a HEAD branch project and a 0.7 maintenance branch project.</li>
	</ol>
	</p>
	<p>
	<img src="figure1.gif"/>
	<img src="figure2.gif"/>
	</p>

	<h2>Checking out from a branch</h2>

	<p>
	To check out from a branch:
	<ol>
	<li>Create a CVS location just like you normally would.</li>
	<li>Expand the HEAD branch, and right click on the project that you want to work with > Configure Branches and Versions...</li>
	<li>A dialog opens. In the <b>Browse files for tags</b> section of this dialog (top left region), select any file that has
	been branched. For example (I branched the <b>component-api.xsd</b> file for testing purposes)
	<br/><img src="figure3.gif"/>
	</li>
	<li>Once you have selected the file, the <b>New tags found in the selected files</b> section (top right region) should be
	updated with the 0.7 maintenance branch name. Make sure only the <b>R0_7_Maintenance</b> branch is checked.</li>
	<li>Click on the <b>Add Checked Tags</b> button.</li>
	<li>Click <b>OK</b>.</li>
	<li>A new branch should be created in your CVS location. You can check out and commit to branch just like the HEAD branch.
	<br/><img src="figure4.gif"/>
	</li>
	</ol>
	</p>

	<p>
	For changes that need to go into both the HEAD and 0.7 branch, I find that retrofitting/merging changes manually is the easiest.
	Since our 0.7 branch is limited to critical and NL fixes only, there shouldn't be too much work. However, if you like the Eclipse
	CVS tools, they do come with some merging tool that you can use. It helps you merge 0.7 branch change back into HEAD.
	This <a href="http://www.eclipse.org/articles/Article-CVS-branching/eclipse_branch.html">article</a> talks about this tool.
	</p>

	<h2>Tracking 0.7 maintenance fixes in bugzilla</h2>

	<p>
	We now have a <b>1.0 M7.1</b> target in bugzilla. I suggest when a fix is retrofitted from the 1.0 stream
	to the 0.7 maintenance stream, we change the target of the corresponding bug to <b>1.0 M7.1</b>.
	We can then create a bugzilla query to see what fixes went into the maintenance stream.
	</p>

	</body>
	</html>