Difference between revisions of "Sirius/Update Sites"

From Eclipsepedia

Jump to: navigation, search
(Update Sites List)
Line 7: Line 7:
 
''Note:'' Each update site is released in one variant per supported target platform (e.g. <code>juno</code>, <code>kepler</code> and <code>luna</code>). 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:'' Each update site is released in one variant per supported target platform (e.g. <code>juno</code>, <code>kepler</code> and <code>luna</code>). 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 [http://download.eclipse.org/tools/orbit/downloads/drops/R20130827064939/repository/ the Orbit update-site] if you want to install Sirius on Juno.  
+
''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 [http://download.eclipse.org/tools/orbit/downloads/drops/R20130827064939/repository/ the Orbit update-site] if you want to install Sirius on Juno.
 +
 
 +
=== Releases ===
 +
 
 +
=== Milestones ===
 +
 
 +
=== Stable Snapshots ===
 +
 
 +
=== Nightly Builds ===
 +
 
  
 
{| border="1" align="center" cellpadding="3" cellspacing="1"
 
{| border="1" align="center" cellpadding="3" cellspacing="1"

Revision as of 07:01, 24 December 2013


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. juno, kepler and luna). 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

Milestones

Stable Snapshots

Nightly Builds

Repository Repository URL Retention Policy
Nightly builds for the 0.9.x stream

http://download.eclipse.org/sirius/updates/nightly/0.9/

Overwritten on each new build.
Stable build for the 0.9.x stream

http://download.eclipse.org/sirius/updates/stable/0.9.0-S20131115-0601/helios
http://download.eclipse.org/sirius/updates/stable/0.9.0-S20131115-0601/indigo
http://download.eclipse.org/sirius/updates/stable/0.9.0-S20131115-0601/juno
http://download.eclipse.org/sirius/updates/stable/0.9.0-S20131115-0601/kepler
http://download.eclipse.org/sirius/updates/stable/0.9.0-S20131115-0601/luna

Kept until the final 0.9.0 release.

General Rules

Note: the rules defined below are not yet finalised and 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 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. 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 numbers 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 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

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.

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.
  • the special string all, which contains all the builds.

A few examples: