Jump to: navigation, search

Difference between revisions of "Sirius/Update Sites"

(Created page with "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 mai...")
 
Line 1: Line 1:
 
[[Sirius]] builds are stored in [[Equinox/p2|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 [[Eclipse/Repository retention policy| retention policy]].  
 
[[Sirius]] builds are stored in [[Equinox/p2|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 [[Eclipse/Repository retention policy| retention policy]].  
 +
 +
The general form of all the Sirius update-sites is the following:
 +
<code><pre>
 +
http://download.eclipse.org/sirius/updates/TYPE/STREAM/TARGET/
 +
</pre></code>
 +
 +
Where:
 +
* ''TYPE'' can be one of:
 +
** '''nightly''': the most recent successful builds from our Continuous Integration server.
 +
*** 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''': these are nightly builds that the Sirius team considers stable enough to be used by early adopters.
 +
*** Guarantees and audience: stable builds should have all the basic functionnality working, but may contain some transient bugs and unfinished features which are still in developement. 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''':
 +
** '''releases''': official Eclipse Sirius releases.
 +
* ''STREAM'' is the Sirius version number. It can be:
 +
** a full version number like <code>0.9.0</code>, <code>1.0.0M5</code>, in which case the individual repositories (one per target, see below) contain exactly this version and only this version; TODO Special rules for different build types. x.y.z-[NS]YYYY-MM-DD, x.y.zMn, x.y.zrcN
 +
** a version stream number ending with <code>.x</code>, like <code>0.9.x</code>, <code>1.x</code>, in which case the individual repositories (one per target, see below) is a composite repository containing all the builds from that type and stream which are still available;
 +
** the fixed string <code>all</code>, in which case the individual repositories (one per target, see below) is a composite repository containing all the builds for that type which are still available;
 +
* ''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. <code>helios</code>, <code>indigo</code>, <code>juno</code>, <code>kepler</code> or <code>luna</code> (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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=374802 this].
 +
 +
Examples:
 +
 +
Lifecycle of a version:
 +
* developement
 +
* milestones
 +
* release
 +
* maintenance
  
  

Revision as of 04:51, 19 November 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.

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

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

Where:

  • TYPE can be one of:
    • nightly: the most recent successful builds from our Continuous Integration server.
      • 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: these are nightly builds that the Sirius team considers stable enough to be used by early adopters.
      • Guarantees and audience: stable builds should have all the basic functionnality working, but may contain some transient bugs and unfinished features which are still in developement. 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:
    • releases: official Eclipse Sirius releases.
  • STREAM is the Sirius version number. It can be:
    • a full version number like 0.9.0, 1.0.0M5, in which case the individual repositories (one per target, see below) contain exactly this version and only this version; TODO Special rules for different build types. x.y.z-[NS]YYYY-MM-DD, x.y.zMn, x.y.zrcN
    • a version stream number ending with .x, like 0.9.x, 1.x, in which case the individual repositories (one per target, see below) is a composite repository containing all the builds from that type and stream which are still available;
    • the fixed string all, in which case the individual repositories (one per target, see below) is a composite repository containing all the builds for that type which are still available;
  • 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.

Examples:

Lifecycle of a version:

  • developement
  • milestones
  • release
  • maintenance


Repository Repository URL Retention Policy
Nightly builds http://download.eclipse.org/sirius/updates/nightly/0.1/ Overwritten on each new build.