There are a couple of "dimensions" of the Higgins 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.
![]() |
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. |
![]() |
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. |
![]() |
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. |