Sirius/Update Sites

Sirius builds are stored in p2 repositories that are produced as part of the build process. This page provides an overview of the different repositories maintained by the Sirius project, and their corresponding location and retention policy.

VERSION is the build version number. See below for the acceptable build versions for each type of build and their meaning.

TARGET indicates the version of the Eclipse platform which was used to build the content of the udpate site. It is the lower-case code-name of the Eclipse release, e.g. helios, indigo, juno, kepler or luna (at the time of this writing). All target variants of a given Sirius build are compiled from the exact same source code, but it is recommended you consume the update-site corresponding to your Eclipse version to avoid binary compatibility issues like this.

Guarantees and audience: there is no guarantee on these versions except that they compiled successfully. These are mostly useful for people contributing to Sirius itself and who want the very latest version.

Frequency: the Continuous Integration server will automatically publish a new nightly every day if there was some activity in the Git repository since the last nightly. The Sirius development team may also decide to trigger manual builds during the day, which get published as nightlies.

Retention policy: for a given stream and target, only the latest nightly build is kept.

Stable Builds

Stable builds are nightly builds that the Sirius team considers stable enough to be used by early adopters and has promoted to stable manually.

Version numbers for nightly builds have the form x.y.z-SYYYYMMDD-HHMM, where S stands for Stable. When a nightly build is deemed to be stable enough to be promoted, the content of the nightly repo is copied as-is under the new location. If the example above (nightly 0.9.0-N20131119-2234) were to be promoted as stable, it would be published at http://download.eclipse.org/sirius/updates/stable/0.9.0-S20131119-2234/luna.

Guarantees and audience: stable builds should have all the basic functionality working, but may contain some transient bugs and unfinished features which are still in development. They can be used by adopters and users who want early access to some features and/or are ready to test unfinished features and give us feedback.

Frequency: there is no fixed frequency, but the development team should publish a new stable release about every two weeks (less than a week between two stable builds is too short to gather feedback, more than 3 weeks means the code is too old compared to the current version).

Retention policy: for a given stream and target, all the stable builds are kept until the next milestone or release from that stream, at which point they disappear.

Milestones

Version numbers for milestone builds have the form x.y.zMn for milestones and x.y.xRCn for release candidates. When a build is promoted as a milestone or release candidate, the content of the build's repo is copied as-is under the new location. If the example above (stable build 0.9.0-S20131119-2234) were to be promoted as milestone M4, it would be published at http://download.eclipse.org/sirius/updates/milestones/0.9.0M4/luna.

Guarantees and audience: milestones should be fully functional and contain no blocker or major bugs. All features included in such a build should be complete (even if in a reduced scope). All automated tests should pass. Manual "open" tests should also be performed with no major issue identified. Exceptions to these rules are possible (to the discretion of the project leads) but should be clearly identified and communicated in the appropriate channels (at least the sirius-dev mailing list, maybe cross-project-issues-dev if some issues can impact other projects in the train).

Frequency: as defined by the plan for the simultaneous release targeted by a stream.

Retention policy: forever.

Releases

Release builds correspond to official Eclipse Sirius releases.

Version numbers for milestone builds have the form x.y.z. When a build is promoted as a release, the content of the build's repo is copied as-is under the new location. If the example above (milestone build 0.9.0M4) were to be promoted as the final 0.9.0, it would be published at http://download.eclipse.org/sirius/updates/releases/0.9.0/luna.

Guarantees and audience: milestones should be fully functional and contain no blocker or major bugs. All features included in such a build should be complete (even if in a reduced scope). All automated tests should pass. Manual "open" tests should also be performed with no major issue identified. Exceptions to these rules are possible (to the discretion of the project leads) but should be clearly identified and communicated in the appropriate channels (at least the sirius-dev mailing list, maybe cross-project-issues-dev if some issues can impact other projects in the train).

Frequency: at least the released implied by the participation in the release train, as defined by the release plan. Additional releases outside of the train may also be published (especially maintenance releases).

Retention policy: forever.

Composite Repositories

All the update-sites described above contain each a single version of Sirius and their content never changes once they are published (until they are removed). For each type of build, we also publish composite repositories which aggregate all the builds of that type for a given stream as they are published. This gives a stable URL that users can point to to always get the latest version of given type of build.

A stream name can be of the form

N.x, where N is a major version number, for example 0.x, 1.x, etc. Such a stream contains all builds with the corresponding major version.

N.M.x, where N.M is a minor version number, for example 0.9.x, 1.2.x, etc. Such a stream contains all builds with the corresponding minor version.

Open Issues

The variants for each target (e.g. helios, indigo, etc.) are build from the same source code but will get different qualifiers. In a way, this is OK because a bundle's name + fully qualified version should be unique. However, how do we decide which timestamp to use for the update-sites? For the first 0.9.0 stable build I chose the start time of the corresponding Hudson job but I did it manually and I'm not sure yet if this is a correct choice and how to automate it.