Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Debug/DebugRelEng

< Debug
Revision as of 14:40, 11 May 2011 by Michael Rennie.ca.ibm.com (Talk | contribs) (Map Files)

Platform Debug
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse Source
JDT Debug
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse Source

Introduction

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:

  1. you have all of the required bundles
  2. you have commit rights to all of the required bundles
  3. you have no pending changes in your RelEng workspace
  4. 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.

They include:

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: org.eclipse.releng

This bundle is available in the default Eclipse CVS repository:

dev.eclipse.org/cvsroot/eclipse/org.eclipse.releng

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.

Releasing Bundles

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:

  1. right-clicking on the selected projects and using the Team > Release... command
  2. 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

Map Files

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 core-variables map.

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.

Build Notes

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 (platform-debug-dev@eclipse.org and jdt-debug-dev@eclipse.org )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.

Choosing Tags

Committing the Release

Back to the top