-
Notifications
You must be signed in to change notification settings - Fork 12
Releasing a scala ide version
Before reading this page, you may want to have a look at the description of the Build Process for one ecosystem
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 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.
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 <site_path>base
site:
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.
- The
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 forstable
anddev
versions.
Here are some hypothetical examples, assumed to happen in
chronological order, with stable releases postfixed with final
for clarity:
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.
After the 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.
1. The Scala Developer's Perspective
2. The Plugin Contributor's Perspective
3. Technical Documentation