Releasing a scala ide version
Clone this wiki locally
Before reading this page, you may want to have a look at the description of the Build Process for one ecosystem
Building a new version of Scala-IDE
An extra profile has been added to the project's top
pom.xml. It is used to set strict dependency to Scala Library and Scala Compiler. It is trigger in the general build script if the system variable
SET_VERSIONS is set to any value.
It should be enabled when creating a version to be added to the ecosystem. It can be run like this:
SET_VERSIONS=true ./build-all.sh <your normal parameters>
The next ecosystem subtree
The next subtree is a staging zone, meaning forthcoming versions of the Scala-IDE plugin are built into the
next hierarchy of the Scala-IDE team's repositories. Note that for one specific forthcoming release (its stable, milestone or RC status notwithstanding), there are usually several versions of the Scala-IDE artifact : one for every (Eclipse × Scala) version we are currently supporting.
This subtree serves as a pre-release emplacement for plugins authors to test the forward-compatibility of their plugins. When a release occurs, the contents of that repository are merged into the root repository of the server (using the Merging tool). The layout of those repositories is described in Plugin maintenance and update.
Releasing from the staging zone
When a new version of Scala-IDE has been flagged for a release , it needs to be folded from
/next/<site_path>/base into the
<site_path>/base update site. It can be done using the Merging tool.
First, duplicate the current
mvn -Drepo.source=http://download.scala-ide.org/ecosystem/<site_path>base -Drepo.dest=~/tmp/ecosystem/base package
Then, merge in the new version of Scala IDE:
mvn -Drepo.source=http://download.scala-ide.org/ecosystem/next/<site_path>/base -Drepo.dest=~/tmp/ecosystem/base package
Finally, the resulting folder needs to replace on the web server.
Layout details and conservation strategy
next/subtree contains a single version of the Scala-IDE for a given flavor. That version is overwritten when a new candidate for release appears, not during the release.
- That being said,
next/reproduces the folder layout for
Here are some hypothetical examples, assumed to happen in
chronological order, with stable releases postfixed with
|I have just pushed||to||contents of /next/.../dev/base||contents of /next/.../stable/base|
|Scala-IDE 2.01-final||/next/<site_path>/stable/base||Scala-IDE 2.01-RC3||Scala-IDE 2.01-final|
|Scala-IDE 2.02-M1||/next/<site_path>/dev/base/||Scala-IDE 2.02-M1||Scala-IDE 2.01-final|
|Scala-IDE 2.02-RC1||/next/<site_path>/dev/base||Scala-IDE 2.02-RC1||Scala-IDE 2.01-final|
|Scala-IDE 2.02-final||/next/<site_path>/stable/base||Scala-IDE 2.02-RC1||Scala-IDE 2.02-final|
- Contrarily to
next, the root subtree retains previous versions of a plugin as well as previous versions of Scala-IDE. The only deletion rule is that for a given flavor (i.e. Eclipse/Scala/Scala-IDE version), only the latest version of a given plugin will be retained.
Regenerating the ecosystem
base site has been updated, the ecosystem build has to be performed again, in order to create whatever plugins can be based from it. The plugin managers that have in the feature site which points to a plugin that can build on this new Scala-IDE release will automatically get the appropriate new version of their plugin. Note that a plugin that had versions built against the
next/base hierarchy right before release fit into that category. When this build is done, users can use the site to install or update to the new version.
The Scala SDK build uses the ecosystem sites by default. It will automatically pick the latest version of Scala IDE and Scala Worksheet.
When the build is done, the content of
org.scala-ide.product/target/repository has to be merged in the existing
base site. The steps are the same as for Scala IDE.
As for Scala IDE, the ecosystem build has to be run after the
base site has be updated, so the new product is available for update.