*** 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).

*** 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.

*** 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''':

+

** '''milestones''': these are [http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#Milestones_and_Release_Candidates milestones and released candidates] as defined in the SimRel rules.

+

*** 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 <code>sirius-dev</code> mailing list, maybe <code>cross-project-issues-dev</code> if some issues can impact other projects in the train).

+

*** Frequency: as defined by the [http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan plan] for the simultaneous release targetted by a stream.

+

*** Retention policy: forever.

** '''releases''': official Eclipse Sirius releases.

** '''releases''': official Eclipse Sirius releases.

* ''STREAM'' is the Sirius version number. It can be:

* ''STREAM'' is the Sirius version number. It can be:

Revision as of 06:03, 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.

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.

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 targetted by a stream.

Retention policy: forever.

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.