This page describes the process for making a formal software release of the NYoSh Workbench.

Review and Update the CHANGELOG.txt file

The changelog file (under project root) needs to be reviewed and edited to reflect most changes introduced in the release. Use git log to review changes since the last  tagged release.  Commit the changelog file once done.

Build Scripts

The build procedure is driven by two scripts included in the StandaloneWorkbench solution of NYoSh project:

  • NYoShWorkbench script generates an Ant script that packages the NYoSh plugin. This script is written in the MPS build language described here.
  • NYoShWorkbenchDistribution script generates an Ant script to build the standalone MPS distribution including the NYoSh plugin and its dependencies. How to build a standalone distribution of MPS is described here.

Build Number

Before to build the workbench, a build number has to be assigned to the release. This is done in the NYoShWorkbench build script.
Build number has to be in the format:


where XX is replaced with the number assigned to the release. 129 is the current MPS platform number (MPS 3.0.1). The workbench has to have the same platform number in order to be accepted as valid plugin. When JetBrains will change the platform number, we have to change ours accordingly.

Enabling automatic updates

Automatic update notifications are made available through an XML file that has be uploaded at The file declares a set of channels with the latest release available for each channel. A channel is basically a stream of releases. When a release is prepared, it is assigned to a channel in the NYoShWorkbench build file (project structure/update website section). An installed workbench periodically checks if a new release (i.e. with a higher build number) is available for the active channel and prompts options to the user for updating the application.

This example shows the format of the update file:

<product name="NYoShWorkbench">
<channel id="NYoShWorkbenchEAP" name="NYoSh 1.0" status="eap" url="" feedback="" majorVersion="1" minorVersion="0">
<build number="NYoShWorkbench-129.11" version="1.0">
<message>NYoSh Workbench 1.0 EAP build 11 is available.</message>
<channel id="NYoShWorkbench" name="NYoSh 1.0" status="release" url="" feedback="" majorVersion="1" minorVersion="0"\>
<build number="NYoShWorkbench-129.11" version="1.0">
<message>NYoSh Workbench 1.0 is available.</message>

For instance, given this file, if a user is running a workbench with build number equals to NYoShWorkbench-129.10 the following pop-up appears:
NYoSh update screen

Packaging a Release

To create a new release package, the StandaloneWorkbench solution of NYoSh project has to be built. This generates the necessary Ant scripts. Next, the Ant scripts has to be executed. This is done by right clicking first on NYoShWorkbench script and select ‘run’ and then doing the same on NYoShWorkbenchDistribution script. If everything works, the following 3 NYoSh packages are created:

  • PROJECT_HOME/build/artifacts/NYoShWorkbenchDistribution/${build.number}-linux.tar.gz: a distribution for the linux plaform
  • PROJECT_HOME/build/artifacts/NYoShWorkbenchDistribution/${build.number} a distribution for the MacOs platform
  • PROJECT_HOME/build/artifacts/NYoShWorkbenchDistribution/${build.number}.zip: a multi-platform distribution

where ${build.number} is replaced with the actual build number.

Uploading a Release on the Website

The three packages generated by the build process have to be uploaded on the website and make available for download. To do that, an account on WordPress is needed. Once logged in, the files have to be uploaded with the FileManager plugin and the category “NYoSh Downloads” has to be assigned to each file. No changes are needed in the download page since it will automatically pick up the new files from the category.

The download page for the NYoShWorkbenchEAP channel is here.

Updating Change Log page on the Website

The NYoSh change log page has to be updated by reporting the most relevant features and bugs fixed in the release. Copy from the project ChangeLog file, but edit for clarity if needed.

Tagging a Release

Once the last commit of the release has been pushed on the remote Git repository, it’s a good practice to tag that commit. Releases in the EAP have been tagged as:

and so on. Spaces are not allowed in the tag.

Push commits to GitHub

Prior to a release, we maintain source code on BitBucket. After a release the commits need to be pushed to GitHub.