Jump to: navigation, search

Difference between revisions of "DTP Build Transition"

(Map Files)
 
(22 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
This page describes the changes that will occur when the DTP build transitions from the current system to a PDE based build infrastructure. While the output of both build systems is functionally equivalent, there are some details that will impact both DTP committers and consumers of DTP.
 
This page describes the changes that will occur when the DTP build transitions from the current system to a PDE based build infrastructure. While the output of both build systems is functionally equivalent, there are some details that will impact both DTP committers and consumers of DTP.
 
==Changes==
 
==Changes==
 +
'''Note:''' There is a tool, described on [[Releng_Map_File_Tool | this page]] that helps with tagging and updating map files.
 +
 
===Map Files===
 
===Map Files===
 
The new DTP build process will use map files. These files specify the features and plug-ins to be included in the build. Further, map files specify a CVS tag for each plug-in and feature. The use of map files is fairly common among Eclipse Foundation projects and brings a number of advantages:
 
The new DTP build process will use map files. These files specify the features and plug-ins to be included in the build. Further, map files specify a CVS tag for each plug-in and feature. The use of map files is fairly common among Eclipse Foundation projects and brings a number of advantages:
Line 9: Line 11:
 
*Consumers of DTP interested in duplicating the build process have a specification of exactly what code was used for a given build.
 
*Consumers of DTP interested in duplicating the build process have a specification of exactly what code was used for a given build.
  
The map files for DTP will be kept in the ''org.eclipse.datatools.releng'' CVS module, to which all DTP committers have write access.
+
There are 5 map projects to hold DTP map files. Each sub-project now has its own "releng" project. (Incubator will also be changed as soon as we finish up a committer election.) So now you have:
 +
 
 +
*HEAD/org.eclipse.datatools.connectivity/releng/org.eclipse.datatools.connectivity.releng
 +
*HEAD/org.eclipse.datatools.enablement/releng/org.eclipse.datatools.enablement.releng
 +
*HEAD/org.eclipse.datatools.modelbase/releng/org.eclipse.datatools.modelbase.releng
 +
*HEAD/org.eclipse.datatools.sqltools/releng/org.eclipse.datatools.sqltools.releng
 +
*HEAD/org.eclipse.datatools.incubator/releng/org.eclipse.datatools.incubator.releng
 +
*HEAD/org.eclipse.datatools.releng
 +
 
 +
We will keep top-level features and doc plugins entries in the top-level map project. And the other 4 are used to hold plugin entries for each sub-projects.
  
 
Naturally, with power comes responsibility. Aside from the obvious requirement to keep the map files and CVS tags current, committers should be very care when adding or removing plug-ins, since doing so can introduce dependencies and build breakage. Therefore, aside from update the existing tags used in the map files, we encourage committers to file bugs with proposed changes (additions/removals/etc.) for review by the release engineering team and PMC ''before'' making such changes.
 
Naturally, with power comes responsibility. Aside from the obvious requirement to keep the map files and CVS tags current, committers should be very care when adding or removing plug-ins, since doing so can introduce dependencies and build breakage. Therefore, aside from update the existing tags used in the map files, we encourage committers to file bugs with proposed changes (additions/removals/etc.) for review by the release engineering team and PMC ''before'' making such changes.
 +
 
===Use of ".qualifier"===
 
===Use of ".qualifier"===
 
As described in the [[DTP_Plug-in_Versioning_Policy | DTP Plug-in Versioning Policy]], "A DTP plug-in version number has four fields, separated by a ".": '''Major.Minor.Service.Qualifier'''"
 
As described in the [[DTP_Plug-in_Versioning_Policy | DTP Plug-in Versioning Policy]], "A DTP plug-in version number has four fields, separated by a ".": '''Major.Minor.Service.Qualifier'''"
  
Previously DTP committers where required to update the qualifier field with each plug-in change. Starting with the new build system, the time stamps in all DTP 1.6 plug-ins will be changed to ".qualifier" and the DTP build process will control update of these values. Thus, no further action in this area is required by DTP plug-in owners.
+
Previously DTP committers where required to update the qualifier field with each plug-in change. Starting with the new build system, the time stamps in all DTP 1.6 plug-ins will be changed to ".qualifier" and the DTP build process will control update of these values.
 +
 
 +
For DTP builds, the source code will be taken from the tags specified in the map files, and the ".qualifier" field in each plug-in will be stamped with the value of the tag. The [[DTP_Plug-in_Versioning_Policy | DTP Plug-in Versioning Policy]] details the format of the tags.
 +
 
 +
===Format of Distribution Version Stamp===
 +
Currently DTP distributions (end user and extender zips) have the following format:
 +
 
 +
* dtp-sdk_1.6M6_20080227.zip
 +
* dtp_1.6M6_20080227.zip
 +
 
 +
with the exact time stamp varying according to the build date. In the new build system, the format will be like:
 +
 
 +
* dtp-sdk-1.6M6-200802251143.zip
 +
* dtp-1.6M6-200802251143.zip
  
The ".qualifier" field will be set to a current time stamp with each DTP build.
+
again, with the exact time stamp varying according to the build date. Consumers relying on a specific format (say for automatic consumption in a build process) might need to update their matching patterns for this change.
===Format of Version Stamp===
+
  
 
===Build Schedule===
 
===Build Schedule===
 +
*Nightly builds take place from Monday to Thursday. Integration builds takes place on Friday.
 +
*DTP builds will take place at [http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=29&year=2008&hour=5&min=0&sec=0&p1=237 5am (Shanghai time)].
 +
*'''DTP committers should refrain from updating map files for +/- 30 minutes around the start of the build, to avoid  version inconsistencies in the map file set.'''
  
===Contact the Build Team===
+
===Contacting the Build Team===
 +
There are a number of ways to contact the build team:
 +
*Create a Bugzilla entry for DTP, using the "releng" component
 +
*Send mail to the [mailto:dtp-dev@eclipse.org DTP development] mailing list

Latest revision as of 03:07, 12 March 2009

Back to DTP Release Engineering

Introduction

This page describes the changes that will occur when the DTP build transitions from the current system to a PDE based build infrastructure. While the output of both build systems is functionally equivalent, there are some details that will impact both DTP committers and consumers of DTP.

Changes

Note: There is a tool, described on this page that helps with tagging and updating map files.

Map Files

The new DTP build process will use map files. These files specify the features and plug-ins to be included in the build. Further, map files specify a CVS tag for each plug-in and feature. The use of map files is fairly common among Eclipse Foundation projects and brings a number of advantages:

  • Committers can use tags to manage which code appears in which build.
  • Committers can update the map files to add or remove plug-ins.
  • Consumers of DTP interested in duplicating the build process have a specification of exactly what code was used for a given build.

There are 5 map projects to hold DTP map files. Each sub-project now has its own "releng" project. (Incubator will also be changed as soon as we finish up a committer election.) So now you have:

  • HEAD/org.eclipse.datatools.connectivity/releng/org.eclipse.datatools.connectivity.releng
  • HEAD/org.eclipse.datatools.enablement/releng/org.eclipse.datatools.enablement.releng
  • HEAD/org.eclipse.datatools.modelbase/releng/org.eclipse.datatools.modelbase.releng
  • HEAD/org.eclipse.datatools.sqltools/releng/org.eclipse.datatools.sqltools.releng
  • HEAD/org.eclipse.datatools.incubator/releng/org.eclipse.datatools.incubator.releng
  • HEAD/org.eclipse.datatools.releng

We will keep top-level features and doc plugins entries in the top-level map project. And the other 4 are used to hold plugin entries for each sub-projects.

Naturally, with power comes responsibility. Aside from the obvious requirement to keep the map files and CVS tags current, committers should be very care when adding or removing plug-ins, since doing so can introduce dependencies and build breakage. Therefore, aside from update the existing tags used in the map files, we encourage committers to file bugs with proposed changes (additions/removals/etc.) for review by the release engineering team and PMC before making such changes.

Use of ".qualifier"

As described in the DTP Plug-in Versioning Policy, "A DTP plug-in version number has four fields, separated by a ".": Major.Minor.Service.Qualifier"

Previously DTP committers where required to update the qualifier field with each plug-in change. Starting with the new build system, the time stamps in all DTP 1.6 plug-ins will be changed to ".qualifier" and the DTP build process will control update of these values.

For DTP builds, the source code will be taken from the tags specified in the map files, and the ".qualifier" field in each plug-in will be stamped with the value of the tag. The DTP Plug-in Versioning Policy details the format of the tags.

Format of Distribution Version Stamp

Currently DTP distributions (end user and extender zips) have the following format:

  • dtp-sdk_1.6M6_20080227.zip
  • dtp_1.6M6_20080227.zip

with the exact time stamp varying according to the build date. In the new build system, the format will be like:

  • dtp-sdk-1.6M6-200802251143.zip
  • dtp-1.6M6-200802251143.zip

again, with the exact time stamp varying according to the build date. Consumers relying on a specific format (say for automatic consumption in a build process) might need to update their matching patterns for this change.

Build Schedule

  • Nightly builds take place from Monday to Thursday. Integration builds takes place on Friday.
  • DTP builds will take place at 5am (Shanghai time).
  • DTP committers should refrain from updating map files for +/- 30 minutes around the start of the build, to avoid version inconsistencies in the map file set.

Contacting the Build Team

There are a number of ways to contact the build team:

  • Create a Bugzilla entry for DTP, using the "releng" component
  • Send mail to the DTP development mailing list