WTP/Build/WTP Build Types

Eclipse Web Tools Platform Build Types

There are a couple of "dimensions" of the WTP Build Types. The "degree of stability" one is that most are familiar with. The "declared vs. continuous" builds is probably not familiar to most, by design, since most everyone only needs to know about the declared builds ... the continuous builds are only for committers and early testers.

Degree of stability

Released Builds

Releases are builds that have been declared major releases by the committers and PMC- for example "R1.0". Releases are the right builds for people who want to be on a stable, tested release, and don't need the latest greatest features and improvements. Released builds always have an "R" at the beginning of the name i.e. R1.0, R2.0 etc. Non-release builds are named according to the date of the build - for example 20011027 is the build from Oct 27, 2001.

Maintenance Builds

Occasionally, we might find there are a few bugs in a Released Build, so a Maintenance Release will be planned. Until a maintenance release is formally declared and released, it will be called a "Maintenance Build", and will have a prefix of "M". This roughly corresponds to "an integration build" but a maintenance build is typically more stable that an I-Build, since the M-build is based on a declared release (not a new release) and M-builds contain bug fixes only ... not new function, as I-builds do. When the maintenance is finalized, approved, and released, it will become a Released Build.

Stable Builds

Stable builds are integration builds that have been found to be stable enough for most people to use. They are promoted from integration build to stable build by the architecture team after they have been used for a few days and deemed reasonably stable. The latest stable build is the right build for people who want to stay up to date with what is going on in the latest development stream, and don't mind putting up with a few problems in order to get the latest greatest features and bug fixes. The latest stable build is the one the development team likes people to be using, because of the valuable and timely feedback.

Integration Builds

All component teams tag their work in what they believe is a stable, consistent state, and they update the build configuration to indicate that the next integration build should take this version of the component. Integration builds are built from these versioned components that have been specified by each component team as the best version available for the next build. These are lightly tested and declared weekly, to be sure everyone stays in synch and doesn't get to a point were it would be hard to react to changes.

Nightly (Head) Builds

"Nightly" builds are produced from whatever has been released into the HEAD stream of the CVS repository. They are completely untested and will almost always have major problems. Many will not work at all. These drops are normally only useful to developers to check the effects of major changes before releasing them to an I-Build. And, typically, these HEAD build can and should be ran by developers "locally" to test major changes.

Note: Nightly (HEAD) builds in the WebTools project are produced only as requested be developers. This should be rarely needed since we don't have any "platform" sensitive parts of the build, and since our code stream is small enough to "pull into" a development environment.

Patch Feature Builds

Under some circumstance the WTP project may find it desirable to produce a "feature patch" which typically includes exactly one jar, that has a fix for exactly one bug. These are done for bugs which happen to be considered extremely severe or blocking -- but may not even apply to all installs, or all users. See WTP Release 1.5.5 Patches for more information.

Degree of committer commitment

Declared Builds

This term simply refers to a build that has been examined, evaluated, and 'declared' by committers and PMC to "be the official one". The reason we use this term is that often there will be some "warm up" period as we approach a declared build, they might have the same name as the declared build, but have not yet been tested nor declared. So, for example, sometimes we have I-Builds that are not yet declared. These are typically not good for adopters to use, and certainly not casual end users. Once the teams are comfortable the build runs as expected, then it is "promoted" to the download page there by becoming a "declared build". So, in general, the term can be applied to any of the other types of builds ... declared I-build, declared Stable Build, etc.(except, Nightly (HEAD) builds would never be declared).

Continuous Builds

This term simply refers to those build that are ran automatically as a result of a committer releasing code to our CVS repository. These builds are not placed on our normal 'downloads' page, but they are placed on a 'committers' area, since typically, only committers and earlier testers will be interested in them.

Note: "releasing code to CVS repository" in our WTP Project means the code it committed to head, it is tagged, and (most importantly) the releng/map files have been updated with that tag and those map files committed to HEAD (or a maintenance branch of releng/maps). We use a tool provided by the platform releng team to make this tagging and updating map files easier, and less prone to typos.

Our typical rhythm is to get all the code which is planned for the week done and released by Wednesday at midnight (EST). Then teams and contributors briefly test those Thursday afternoon builds to be sure there are no problems that would interfere with its use in further development. If no "blockers" are announced by Thursday 2 PM (ET), that build is promoted to "the declared weekly I-Build". Committers are not to release code between Wednesday at midnight and the time the weekly build is promoted, except for blockers, to avoid destabilizing the weekly declared I-build.