Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


< Platform-releng
Revision as of 16:24, 26 February 2016 by David (Talk | contribs) (/* After any Release)

This page is to provide a checklist of "release engineering" tasks that must be done at various stages of development.

Note: this page is "just getting started" and will be added to incrementally, as phases are gone through and new things remembered to document. Also, as it develops the structure may change substantially, so "header links" may not stabilize for a while, and hence would be best not to use headers in links ... at least for a while, until it takes it's final form.

Before Major (June) release

lots to come, for this section

After Major (June) release

Update no-version-in-url repository composites

  • Update the 4 repo composites that have no version in URL (I-builds, M-builds, N-builds, milestones)

After any Release

  • Prepare bugzilla to guide and remind us to "Tag a Release".
  • Prepare bugzilla (and code) to update the parent pom to "next version". That is, when a "next version" is planned. For example, after "4.5.2" we do not automatically change to "4.5.3". Any long term maintenance is done is seen as "patch builds" of 4.5.2 (usually denoted 4.5.2+ in bugzilla) -- it is not a "new release stream".
  • Update any "info center" bugs with our latest collection of 'doc bundles'. As one example of one, see bug 477616.
  • Add the N&N, acknowledgments and readme links to the download page. These are automated in the "promote script" to avoid manual edits, but will describe here in case there are issues. In short, the promote script adds three variables to the buildproperties.php file when it is renaming/promoting to an "R-build" : $NEWS_ID, $README_ID, $ACK_ID. And, from those, the index.php file has conditions based on 'isset' that will compute the full URL. For example, for any Release in the 4.5.x stream, the promote script adds the following variable=value pairs buildproperties.php:
 $NEWS_ID = "4.5";
 $ACK_ID = "4.5";
 $README_ID = "4.5";
  • Copy the release to "archives". While it would seem not to be required until it is removed from "downloads" page, it is a good idea to do it early. This is partially just so it does not have to be done later when it is removed from DL page. But more important, some adopters may like to use the "archives" URL in their own builds simply so that their build script never has to change. This, I have heard, is a common practice at Apache sites. [Note: this is automated for Equinox, so it is done by the same script that promotes Equinox releases but is not yet automated for Eclipse.]
  • There are a few places in our builds where "previous release" is specified. That should be updated to the new "previous release". (It is best to search the aggregator project for the previous release version to find the spots that need to be updated.)
The following are the files that needed modifying after the 4.5.2 release (but, things may change over time). See this commit log entry for more details of this specific case.


Build Calendar

  • Be sure build calendar is up to date (ideally, at least a few weeks before the milestone).

Stabilization Week


  • For milestone stabilization week, the nightly cron jobs are disabled, twice daily I-build cron jobs enabled.
[TODO: perhaps provide copy of "current cron jobs" for illustration?]

Repo Information for Gerrit jobs

  • A maven variable, eclipse-p2-repo.url, is defined in the build-individual-bundles profile. Normally this variable points to N-builds, so that Gerrit jobs can "use the latest" of things it does not build. However, during "stabilization week" and similar, we stop doing N-builds and do frequent I-builds instead. At such times, the Gerrit jobs may with to change the eclipse-p2-repo.url variable to point to the I-build repo instead of the N-build repo.
- This does not require a republish of the parent pom because the change should be done in the Gerrit job itself, or in their settings.xml file or other "shared settings". As a "command line" example, -Declipse-p2-repo.url=<what ever repo is desired>. The parent's POM value using 4.x-N builds is simple a reasonable default for most situations.

Create and monitor "sign-off" bug

  • Typically created after last I-build is complete, but can be created earlier.
  • Project leads are added to CC
  • Typically note is sent to platform-releng-dev, as added reminder, and so everyone can know, if interested.

Do special releng tests

Some of these may be automated eventually ... but, until then ...
  • Run b3 aggregator, at least locally, to see if any issues
  • Confirm all jars are signed
  • sanity check version numbers, names, etc. (i.e. run "repo tests" locally, until automated)
  • confirm can "update" from previous milestone

Promote the milestone

Happens after signed off ... though some initial steps can be done early if fairly confident all is well because the build remains "hidden" until the deferred steps are performed.

Initial step

  • add "testNotes.html" to buildDirectory, with sign-off bug number. [TODO: automate]
  • Initial step: run the "promote" job from appropriate directory, with appropriate changes for the I-build to promote, what labels should be. This puts artifacts "in place" but, "invisible" until deferred step. (This allows the promotion to be done "early" possible before all sign-offs, but also to allow some mirroring to occur, before being made visible.)

Deferred step

  • Deferred step: run the "deferred steps" script (which would have been created as part of the initial promotion job). This makes things visible and tags the aggregator.

After milestone promotion


  • Change cron jobs back to their normal schedule (nightly N-builds, weekly I-builds).

Gerrit jobs reference

  • After first N-build, Gerrit jobs should change their eclipse-p2-repo.url back to point to N-builds repo if it was ever changed to point to the I-builds repo.

Back to the top