View source for CDT/Obsolete/release engineering

{{warning|Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits. Please see the CDT GitHub page at https://github.com/eclipse-cdt/cdt for current information.}}

[[Category:CDT:Obsolete]]

__TOC__

== What do we build today? ==


CDT is currently built as an update site, archived in a master zip file.


To install CDT: 
# Download the master zip file and put it somewhere on your machine.
# Fire up Eclipse
# Help->Software Updates
# On the Available Features tab, select Manage sites...
# Add... in the master zip as an Archive...
# Under CDT Main Features select the one you want. C/C++ Development Tools is the main one. The SDK adds in the schemas and source for building extensions to the CDT. The C/C++ Development Platform is the Tools without the GNU toolchain support.
# You can install other neat things from th CDT Optional Features category.


This master zip has everything, including:
* CDT Platform Feature - includes editor, search, builders, launch, debug, user documentation
* CDT Runtime Feature - superset of platform feature that adds gnu toolchain integrations for build/debug
* CDT SDK Feature - superset of runtime that adds source and extension point schemas
* GDB Hardware Debugging - provides a launch configuration for launching gdb to do hardware debugging.
* XL C/C++ Compiler Support - provides an error parser and managed build support for IBM's XL C/C++ compilers.
* LR Parser - provides a parser for the ISO/IEC 9899:1999 variant of the C programming language (aka C99) and the C++ programming language, generated from a grammar using the LPG parser generator. The grammar can be reused and extended to create your own parser for variants on the C programming language.
* Unified Parallel C Support - Provides support for the Unified Parallel C programming language. Provides parsing/indexing infrastructure and language definition, allowing the UPC language to be recognized by CDT. Requires the LR parser feature.
* CDT Utilities - provides utilities for C/C++ Development Tools
* CDT Testing Feature - includes all test plugins required for running automated JUnit tests


==Building CDT master headlessly with Tycho/Maven==

CDT master is built from git using Maven+Tycho.  Running a headless build is straightforward.  (Within the IDE, plugins are automatically built.) Note that Tycho requires Maven 3.0. You can download it directly from Apache.

===Building CDT===
# mkdir cdt-releng ; cd cdt-releng
# git clone git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
# pushd org.eclipse.cdt
# mvn clean install
# popd

Add ''-Dmaven.skip.test'' if you don't want maven to run the tests.

The generated p2 repository lives under: '''releng/org.eclipse.cdt.repo/target/repository/''' or compressed at: '''releng/org.eclipse.cdt.repo/target/org.eclipse.cdt.repo.zip'''

==How do we run the build? How often do we build?==

Recent release streams use maven to build and run on [[https://ci.eclipse.org/cdt/ CDT's Jenkins instance]]. Consult the Jenkins machine for details on each job. 

{| border="1"
|-
! Script
! CDT version
! Git branch
! Java JRE
|-
| mvn clean install
| CDT 9.7
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=master master]] - until branch is created around release time
| Java 8
|-
| mvn clean install
| CDT 9.6
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_6 cdt_9_6]]
| Java 8
|-
| mvn clean install
| CDT 9.5
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_5 cdt_9_5]]
| Java 8
|-
| mvn clean install
| CDT 9.4
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_4 cdt_9_4]]
| Java 8
|-
| mvn clean install
| CDT 9.3
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_3 cdt_9_3]]
| Java 8
|-
| mvn clean install
| CDT 9.2
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_2 cdt_9_2]]
| Java 8
|-
| mvn clean install
| CDT 9.1
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_1 cdt_9_1]]
| Java 8
|-
| mvn clean install
| CDT 9.0
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_9_0 cdt_9_0]]
| Java 8
|-
| mvn clean install
| CDT 8.8
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_8 cdt_8_8]]
| Java 7
|-
| mvn clean install
| CDT 8.7
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_7 cdt_8_7]]
| Java 7
|-
| mvn clean install
| CDT 8.6
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_6 cdt_8_6]]
| Java 7
|-
| mvn clean install
| CDT 8.5
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_5 cdt_8_5]]
| Java 7
|-
| mvn clean install
| CDT 8.4
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_4 cdt_8_4]]
| Java 7
|-
| mvn clean install
| CDT 8.3
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_3 cdt_8_3]]
| Java 6
|-
| mvn clean install
| CDT 8.2
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_2 cdt_8_2]]
| Java 6
|-
| mvn clean install
| CDT 8.1
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_1 cdt_8_1]]
| Java 6
|-
| mvn clean install
| CDT 8.0
| [[http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/log/?h=cdt_8_0 cdt_8_0]]
| Java 5
|-
| cdtbuild
| CDT 7.0
| cdt_7_0
| Java 5
|-
| cdtbuild6.0
| CDT 6.0.2
| cdt_6_0
| Java 5
|-
| cdtbuild5.0
| CDT 5.0.3
| cdt_5_0
| Java 5
|}


These scripts setup the staging area on the build machine for the build.

Builds for CDT 8.0 and more recent are run using Maven.

Scripts for CDT 7.X and earlier check out the latest ''org.eclipse.cdt.releng'' plugin in their respective stream. It then runs ''build.sh'' and ''build.xml'' (in ''org.eclipse.cdt.releng'') where majority of the build logic resides. We rely on the plugins in ''org.eclipse.releng.basebuilder'' to run our builds.  We use different versions of the basebuilder for various stream builds.  More information can be found on http://wiki.eclipse.org/Platform-releng-basebuilder. During the build process, features and plugins are tagged in CVS with the build timestamp.  Once the build is completed, it is signed, (JUnit) tested, and made available in the [http://download.eclipse.org/tools/cdt/builds | CDT download area].


Builds against older streams may be available upon request to [[https://accounts.eclipse.org/mailing-list/cdt-dev cdt-dev mailing list]].

==Miscellaneous release checklist==
This is a list of things that need to be done at some point before a release.

* Verify that our target file points to the proper Orbit release, as listed in http://download.eclipse.org/tools/orbit/downloads/
** This should be done until the version of Orbit targeted to the Simultaneous release is available
* A release record must be created for the release (by project leads).
** This can be done much in advance to notify users of upcoming releases and normally be done by M1 for releases joining SimRel
** This can also be done for maintenance release (no API change, no new features) but such release do not need a review
* An entry on https://wiki.eclipse.org/CDT/User/NewInCDT should be created for minor and major releases. Maintenance releases can add to existing pages.
* Old .api_filters files of the previous release can be removed (not necessarily '''all''' .api_filters though). To easily and safely find the unused ones:
** Go to the Problems view and in its menu choose "Group By -> Type"
** Sort the "Type" column
** Remove all .api_filters file (optionally using the quick-fix) that correspond to the warnings "Unused API Problem Filter Problem"
* Update all the feature versions using Maven to the upcoming release number. All feature versions should match the release; on the other hand plugins are only bumped to their own next version if they have changes. (The exceptions are the '''org.eclipse.cdt''' and '''org.eclipse.cdt.sdk''' plug-ins which have the same version as the feature.)
** Using Find and Replace find all instance of current version and change them to new version.
** Do a grep of the code against the old version to make sure nothing is left, for example in the root of the repo run: <code>git grep 9\\.3\\.3</code>
* Update all p2.inf file to point to the p2 repo. 
** Right now there is only one in CDT's repo that has an update site: releng/org.eclipse.cdt-feature/p2.inf
** But there is one in epp too: https://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/tree/packages/org.eclipse.epp.package.cpp.feature/p2.inf
* Update dependent versions in MANIFEST.MF of org.eclipse.cdt.core/ui to be the same as the versions in cdt.target. See https://git.eclipse.org/r/#/c/143148/ for an example, including a commit message.
* Make sure https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment is being followed
* Add version to Bugzilla
* Add next target milestone to Bugzilla (if known)
* Ensure that doc bundles have had version numbers bumped if the eclipse run version has changed. (For example, see https://git.eclipse.org/r/#/c/149205/)

==How do we release builds?==
'''Steps for Milestones'''

Milestone 1 is the "intent" milestone, so CDT should at least "touch" the cdt.aggrcon file to indicate intent. In addition release record should be created by M1 and shortly after M1 check that under the "Release Date" section it says the appropriate "This release is part of Eclipse IDE ??????".

This is the release process to be done on the day of the release (for CDT this is the +1 day for the simrel). 

# See if any steps of the miscellaneous release checklist needs to be done
# A milestone is a good time to update the cdt.target file to point to the most recent dependencies
## To find the latest dependencies, one can look at what is made available in the most recent simrel git repo
## Update all necessary dependencies in cdt.target
# Ensure the build is stable - it is always better to release a "Green Dot" build
# Run [https://ci.eclipse.org/cdt/view/Releng/job/Promote%20a%20cdt%20build%20from%20jenkins/ Promote a cdt build from jenkins]
#* Consider re-running a previous build to simplify pre-populate the build variables
# When the promotion is done you will have a p2 URL similar to http://download.eclipse.org/tools/cdt/builds/9.7/cdt-9.7.0-simrel-2019-03-m1
# Smoke test the released build against the corresponding Eclipse Platform for the milestone (Note: Platform does not release an official M2, simply an I build is promoted)
# Mark the promoted build as Keep Forever 
# Label the promoted build and the releng job with the version and simrel it is being contributed to
# Using the [https://wiki.eclipse.org/CBI/aggregator CBI aggregator tooling] update [https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/cdt.aggrcon cdt.aggrcon] in simrel's [https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/ git repo]. An example of a previous contribution is in [https://git.eclipse.org/r/#/c/135069/ gerrit]
# Notify the cdt-dev list that the build was posted. An example is available on [https://www.eclipse.org/lists/cdt-dev/msg33395.html cdt-dev archives]

The final part of the release is to wait for announcement (normally on +4 day) like [https://www.eclipse.org/lists/epp-dev/msg05332.html this] on [https://accounts.eclipse.org/mailing-list/epp-dev epp-dev] and smoke test the EPP build and confirm operation with a +1 to epp-dev mailing list.

'''Steps for the RC1 or RC2 milestone'''

The below steps do '''not''' apply to maintenance releases which are built from a branch already
# Optionally copy the new and noteworthy to the user documentation in the git repo, doc/org.eclipse.cdt.doc.user/concepts/cdt_c_whatsnew.htm
#* This makes the documentation grow substantially.  Instead, we can opt to simply include the latest link to the N&N on the web
# Create a branch from master for the release e.g., cdt_9_0.
# Create a new location for the release on the build machine.  E.g.,
#* Log on to build.eclipse.org
#* cd downloads/tools/cdt/builds
#* mkdir 9.0
#* mkdir 9.0/nightly
# Modify the root pom.xml file to point to a new location for the release. E.g.,
#* <repo-path>tools/cdt/builds/9.0/nightly</repo-path> and <cdt-site>http://hudson.eclipse.org/cdt/job/cdt-9.0/lastSuccessfulBuild/artifact/releng/org.eclipse.cdt.repo/target/repository</cdt-site>
#* Commit this change to the release branch (not master)
# Create a new HIPP job to build the '''new branch''' (can be copied then modified from an existing one)
#* Trigger the new job.  The result will be the RC1 to use in the steps below
#* Optionally delete the oldest build branch and job if it is no longer needed
# Perform general milestones steps below
# Notify the cdt-dev list about the situation and mention that bug fixes should go in both master and the branch

'''Steps during Quiet week'''
* Add the documentation to the info center ([http://help.eclipse.org http://help.eclipse.org]). This is required every simulaneous release (June release) or if the documentation was updated in a service release. For an example of how to do it, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=436372#c18
* The below steps assume that RC4 is available by the above steps
'''Should ONLY be done with RC4 as the mirrors will trigger right away'''<br>
'''Should be done early during quiet week to give enough time for mirrors to sync (can be done as soon as RC4 is released)'''
# Log on to build.eclipse.org 
# cd downloads/tools/cdt/
# Copy the RC4 build into the release location (releases/[release_name]).  E.g., for 9.0:
#* mkdir releases/9.0
#* cp -R builds/neon/milestones/rc4 releases/9.0
#* mv releases/9.0/rc4 releases/9.0/r
# Rename and move zip file
#* mv releases/9.0/r/cdt-9.0rc4.zip releases/9.0/cdt-9.0.0.zip
# Make build 'invisible' until release day
#* mv releases/9.0/r/artifacts.jar releases/9.0/r/artifacts.jar.tmp
#* mv releases/9.0/r/content.jar  releases/9.0/r/content.jar.tmp
#* mv releases/9.0/r/artifacts.xml.xz releases/9.0/r/artifacts.xml.xz.tmp
#* mv releases/9.0/r/content.xml.xz  releases/9.0/r/content.xml.xz.tmp
# Copy and update the index.php file for RCP stand-alone debugger of the previous release
#* cp releases/8.8/r/rcp/index.php releases/9.0/r/rcp/index.php
#* Update the file by changing the CDT version number (in two locations of the file)

'''Morning of the release'''
# Verify we get a GO on the cross-project-issues-dev mailing list
# Make the release visible
#* Copy the two composite*.xml file of the previous release to this release and update them
#** cp releases/8.8/composite*.xml releases/9.0
#** Manually update ''both'' the files to change the name of the release ("repository name" entry")
#* mv releases/9.0/r/content.jar.tmp  releases/9.0/r/content.jar
#* mv releases/9.0/r/artifacts.jar.tmp releases/9.0/r/artifacts.jar
#* mv releases/9.0/r/artifacts.xml.xz.tmp releases/9.0/r/artifacts.xml.xz
#* mv releases/9.0/r/content.xml.xz.tmp  releases/9.0/r/content.xml.xz
# Tag the release (it is best to wait until the day of release in case of re-spins) Example: '''git tag -a CDT_9_4_2 2cdc63eae52c8952c0d2543e1e31ca6e25225c4a -m"CDT 9.4.2" && git push origin CDT_9_4_2'''
# Update the website (index.php, downloads.php), the website can be modified using this git repo: [https://git.eclipse.org/c/www.eclipse.org/cdt.git/ https://git.eclipse.org/c/www.eclipse.org/cdt.git/]
# Notify the cdt-dev list
# Update the cdt-baseline.target file to the new release on '''both''' master and the maintenance branch.
#* Ensure that the cdt-baseline includes any new features/plug-ins so that they are baselined as appropriate
# Update new and noteworthy on the wiki. Also update the link to it in the [[CDT|main CDT wiki page]]. And the [[CDT/User/NewInCDT| new in CDT page]].
# Update wiki pages if necessary:
#* [[Getting_started_with_CDT_development|Getting started]]
#* [[CDT/contributing|Contributing]]
#* [[CDT/policy|Policy (especially API tooling section)]]
#* [[CDT/git|Using Git with CDT]]