The Eclipse Development Process (EDP) regards a release as a pretty significant event. A release is similar to what other organizations might call a general availability release (GA), or ship event. A release is generally associated with some form of enhanced quality assurance testing and marketing. A release is intended for the widest possible audience of users, adopters, and downstream consumers. How often these events occurs varies from open source project to project: some projects release annually and others release more frequently. Some open source projects don’t release at all (I tend to think of these projects as potential candidates for termination; but I’ll save that discussion for another day).
The EDP goes to painful lengths to avoid using the word release in any sense other than the aforementioned significant event, referring instead to various types of builds with an implication that these builds are made available for download by target audiences.
Nightly builds—as the name suggests—are the product of an automated build process that runs every night. Nightly builds often break automated tests. They are intended primarily for testers and developers, and are not inappropriate for general consumption. Nightly builds are short-lived, remaining accessible for a few days at most.
Integration builds are created less frequently than nightly builds; the EDP makes no specific requirement regarding how often these are created, but many projects generate weekly integration builds. A lot more care is taken to ensure that integration builds do not break tests. Integration builds tend to target a slightly larger audience, e.g. adopters and other downstream development teams. Like nightly builds, integration builds are short-lived; project teams typically keep a small number of the most recent integration builds accessible at any time.
Milestone builds are a bit more of an event. They pass all automated tests and are intended for a much broader audience of bleeding edge users and adopters. The primary intent of issuing a milestone build is to solicit feedback on an upcoming release (milestone builds are tied to a future release). The cadence for milestone builds varies by project. The annual simultaneous release does seven milestone builds and three release candidates (the EDP regards milestone and release candidate builds as equivalent). The pace is one milestone build every six weeks with release candidates coming more frequently in the weeks leading up to the release.
Releases come in three different flavours: major, minor, and service. A major release indicates that major changes, including API breakage or including significant new functionality. A minor release introduces new functionality, but maintains backwards compatibility with the previous release. A service release includes bug-fixes only and—like a minor release—is backwards compatible.
As a service to the community (and in order to conform to the EDP), releases and builds must be consistently labelled.
Release names follow a common three-digit version numbering scheme: x.y.z indicating a major, minor, and service number. Note that the release name does necessarily need to be reflected in the technical implementation. A hypothetical zip-file download would carry the name of the release, but may contain (for example) OSGi bundles with a variety of different version numbers (i.e. only rev the version number of individual bundles as is required for technical reasons). Trailing zeros are optional.
Milestone build names leverage the name of the release that they’re tied to and are indicated with either an “M” or an “RC” in the form x.yMn (e.g. 3.8M2 or 3.8RC1 are milestone builds for a future 3.8.0 release).
Integration builds should take the form “I<date>-<time>” (e.g. I20160216-0800); nightly builds take a similar form, but with an “N” prefix. Note that our mirroring process uses this naming convention to limit the propagation of integration and nightly builds to our mirrors (the full exclude list is captured in the IT Infrastructure FAQ).
The frequency and types of builds that a project creates leading up to a release varies widely and is dependent on numerous variables, many of which are specific to (and best known by) the project team. The Eclipse Foundation expects that project teams know their community and consumers and work with them to sort out the best strategy.
Note that we’ve created a new incubation mailing list specifically for new project teams to pose questions to their peers and the Eclipse Architecture Council. This is the best possible place to ask questions about process.
