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

Eclipse UML Generators/Update Sites


Eclipse_UML_Generators 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 UML Generators 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. luna and mars). 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: UML Generators depends on a version of the Guava library: the Orbit update-site.

Releases

Milestones

Stable Snapshots

  • UML Generators 1.0.0-S20151029-124829: http://download.eclipse.org/umlgen/updates/stable/1.0.0-S20151029-124829: Luna, Mars

Nightly Builds

General Rules

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

http://download.eclipse.org/umlgen/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. luna or mars (at the time of this writing). All target variants of a given UML Generators 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.

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/umlgen/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 UML Generators itself and who want the very latest version.
  • Frequency: the Continuous Integration server will automatically publish a new nightly every hour if there was some activity in the Git repository since the last nightly. The UML Generators 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 UML Generators 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/umlgen/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. Note that UML Generators does currently not follow the SimRel.

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/umlgen/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 umlgen-dev mailing list).
  • Frequency: a bit less than Stable builds. If UML Generators joins the SimRel, this will be defined by the plan for the simultaneous release targeted by a stream.
  • Retention policy: forever.

Releases

Release builds correspond to official Eclipse UML Generators 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/umlgen/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 umlgen-dev mailing list.
  • Frequency: depending of the evolution and maintenance plan. At least the released implied by the participation in the release train, as defined by the release plan, if UML Generators joins the SimRel.
  • Retention policy: forever.

Shortcuts

All the update-sites described above contain each a single version of UML Generators 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:

Back to the top