|Mailing List • Forums • IRC • mattermost|
|Open • Help Wanted • Bug Day|
|Mailing List • Forums • IRC • mattermost|
|Open • Help Wanted • Bug Day|
Being part of the Eclipse platform requires that for each I-build in the Eclipse build schedule all of the debug plugins must be released to the build.
This process only has a few requirements:
- you have all of the required bundles
- you have commit rights to all of the required bundles
- you have no pending changes in your RelEng workspace
- the RelEng tools are installed in your host Eclipse
There is also another pretty good write-up on how to release bundles on the EclipseSource blog
Bundles Needed To Release
The bundles that must be released each week can be found in the project set file.
org.eclipse.core.variables org.eclipse.debug.core org.eclipse.debug.examples.core org.eclipse.debug.examples.ui org.eclipse.debug.tests org.eclipse.debug.ui org.eclipse.jdt.debug org.eclipse.jdt.debug.tests org.eclipse.jdt.debug.ui org.eclipse.jdt.launching org.eclipse.jdt.launching.macosx org.eclipse.jdt.launching.ui.macosx org.eclipse.ui.console
There is an additional required bundle that contains all of the map files that must be updated, which is:
This bundle is available in the default Eclipse CVS repository:
The RelEng Tools
The key to being able to release all of the bundle is to use the Eclipse RelEng tools.
These tools do not come installed in Eclipse by default, but can easily be installed from any of the release update sites. For example the Indigo update site.
Alternatively download it as an archive. The link to the archive at the bottom of any build page. Then select Help > Install New Software > Add Site > Archive. After adding archive, select it and make sure to uncheck "Group items by category".
To confirm that the RelEng tools have successfully been installed simply select a debug project in your workspace, right-click, select the
Team fly-out menu and look for the
Release... command. If the
Release... command is present the tools are installed and ready to go.
With the RelEng tools installed and working, and all of the required projects selected you must start the
Release wizard by doing one of the following:
- right-clicking on the selected projects and using the Team > Release... command
- click the Release Projects toolbar button in the main toolbar. This option is not available by default, so to use it you first must go to Window > Customize Perspective and enable the command group for RelEng Tools
If you have used the wizard before and told it to not ask for a map project anymore, you will not see the following page of the wizard. If this is your first time, the first page of the
Release wizard asks you to select the map file project.
For the debug projects this will always be
org.eclipse.releng. If at some point you have told the wizard to always use a given project, and would like to choose another - i.e. once again show you the first page of the wizard above - you can enable the option to always ask for map projects on the Team > Releng Map Project Selection preference page within Eclipse.
With the map file project selected, the next step allows you to select all of the projects you want to release. You can see in the following screen shot that all of the projects we selected in the workspace are initially selected and they presented grouped under the map file they belong to.
It is expected that all of the debug projects appear under the
jdtdebug map and that
org.eclipse.core.variables appears under the
There is a very important preference on this page, it is the Release only projects that have changed since the last release preference. When this option is checked the wizard will consult CVS to find what change have been made to the projects since the last time the bundles were released. If the wizard finds no changes the bundles will not be released. If you want to tag all of the bundles regardless of changes since the last release, you must un-check this option. Doing so will also cause the wizard to skip past the Project Changes and the Notes for Build Changes pages mentioned below.
The last step in choosing what and where to release is to view the changes that have been found since the last time the bundles were released. If, however, you un-checked the only released changed projects... option from above you will not see this page.
This page also contains an important, but often overlooked option - the Generate Build Notes option. This option will consult CVS and collect all of the commit comments for any of the project changes it shows you on this page. The advantage of using this is so you can easily send the status email once the bundles are released. More on this in the next section.
First thing to note is, if you un-checked the only released changed projects... option mentioned above, you will not be presented with this page. If you left that option checked and also left the Generate Build Notes option mentioned above checked, you will see the Notes For Build Changes page.
This page allows you to automatically update a build notes file - which we do not use in debug - and presents you with a nicely formatted text blurb of all of the commit comments for the changes that will be released. At this point you will want to copy that text as it is used in the status email that must be sent to the debug mailing lists (firstname.lastname@example.org and email@example.com )after the release is complete. The reason for this is so that the other debug committers (and any other interested parties) know what fixes / enhancements will be available in the next I-build. Also it lets the other committers know that the bundles have been released.
Other than making sure you are releasing all of the correct changes, selecting the right tag is probably the most important step in the process. Typically, using the drop-down and selecting the first selection will be fine, but there are exceptions.
- if you have to release the same bundle more than once on the same day you must add a postfix to the tag and never select the option to move the tag if it exists. For example say you released the bundles under the tag
v20110511at noon, but then later in the day a new fix was added and you had to re-tag. In this case the default choice would again be
v20110511, but you already used it. In this case the de-facto standard debug uses is to append a letter to the tag as needed:
v20110511b, etc, etc for as many times as you release the bundles in the same day.
- if you need to tag the bundles for a particular release for a non-HEAD branch. In this case it is the de-facto standard for debug to add a postfix about the branch to the tag name. For example if you had to release the bundles in the
R3_6_maintenancebranch you would use something like:
The absolutely most important part of choosing tags is to never EVER select the option to move a tag if it already exists. This can cause all kinds of problems in the Eclipse build process.
After you have selected the tag you want to use, the next page allows you to view the changes that will be made to the map files.
Committing the Release
This one is easy. You have to enter a commit comment and press the finish button to perform the release.