Updated 2005-08-03

Branch name: R0_7_maintenance

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 releng and the releng.builder 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.

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.

Creating a branch for a plug-in/feature is fairly easy, here's a laundry list of what needs to be done:

1. Check out the plug-in/feature project that you want to branch.
2. Right click on the project > Team > Branch...
3. Enter R0_7_maintenance as the branch name > OK.
4. 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.

To check out from a branch:

1. Create a CVS location just like you normally would.
2. Expand the HEAD branch, and right click on the project that you want to work with > Configure Branches and Versions...
3. A dialog opens. In the Browse files for tags section of this dialog (top left region), select any file that has been branched. For example (I branched the component-api.xsd file for testing purposes)
   
4. Once you have selected the file, the New tags found in the selected files section (top right region) should be updated with the 0.7 maintenance branch name. Make sure only the R0_7_Maintenance branch is checked.
5. Click on the Add Checked Tags button.
6. Click OK.
7. A new branch should be created in your CVS location. You can check out and commit to branch just like the HEAD branch.
   

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 article talks about this tool.

We now have a 1.0 M7.1 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 1.0 M7.1. We can then create a bugzilla query to see what fixes went into the maintenance stream.