Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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.

Update Sites List

Note: Each update site is released in one variant per supported target platform (e.g. mars and neon). All variants of a given update site correspond to the exact same source code, but built against a different base Eclipse version. We recommend you use the update site corresponding to you Eclipse version (it can prevent some issues with broken binary compatibility between releases).

Note 2: Sirius depends on a version of the Guava library which is not available by default from a Juno install. You need to add the Orbit update-site if you want to install Sirius on Juno.

Releases

Only the latest release of each stream/branch is visible here. See the list of all Sirius-related pages to find other specific releases (each one has a page).

Milestones

Note that these are only temporary repositories, and will be removed without notice sometime after the corresponding version is officially released.

Stable Snapshots

Note that these are only temporary repositories made for specific (generally internal) purposes. They will be removed without further notice once their initial purpose has been fulfilled.

Nightly Builds

General Rules

Note: the rules defined below are not yet finalized and fully implemented. See the discussions at https://bugs.eclipse.org/bugs/show_bug.cgi?id=422069. Feedback welcome.

The general form of all the Sirius update-sites is the following: 

http://download.eclipse.org/sirius/updates/TYPE/VERSION/TARGET/

Where:

  • TYPE can be one of: nightly, stable, milestones, releases.
  • VERSION is the build version identifier. 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 update site. It is the lower-case code-name of the Eclipse release, e.g. 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.

Nightly Builds

Nightly builds correspond to the most recent successful builds from our Continuous Integration server.

Version identifiers for nightly builds have the form x.y.z-NYYYYMMDD-HHMM, where N stands for Nightly.

For example, the nightly built for Luna on November 19, 2013 at 22:34 would be published at: http://download.eclipse.org/sirius/updates/nightly/0.9.0-N20131119-2234/luna.

  • 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 last 10 nightlies are kept. This does not necessarily correspond to 10 days, as we sometimes launch several builds per day.

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 strive to 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

Milestone builds correspond to the milestones and released candidates as defined in the SimRel rules.

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.

Shortcuts

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 shortcut URLs which point to the latest 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.
  • the special string latest, which always point to the latest build (from the master branch), whatever is/will be its version version when released.

A few examples:

Retrieved from "https://wiki.eclipse.org/index.php?title=Sirius/Update_Sites&oldid=448705"

This page was last modified 13:11, 10 March 2024 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top