TCLethbridge edited this page Jun 30, 2018 · 12 revisions


Umple is continually built, meaning that people can get the latest cutting-edge version of the umple.jar after every commit. This is also the version used by UmpleOnline/

The fourth component of the version number is updated after every commit, identifying each such cutting-edge release.

However, periodically, want to update the third, second or even first component of the version number and make available a version of Umple that will remain stable. More importantly, we want to ensure that the the build server, and those who download the official compiler or Eclipse plugin are not left with an older release, so we declare that at a snapshot in time the official downloadable version of the compiler, the plugin and other tools is to be the current cutting-edge version. This is called 'doing a release'

Releases of Umple must be discussed and agreed to by project leaders. Generally a release is done once we are satisfied that some important changes are working properly. Once it is agreed to do a release, then one of the committers should follow the steps on this page.

Release numbering in Umple

  • The first digit will remain 1 until we do some kind of radical change, making generated code incompatible with generated code for release 1. That may never happen, although we anticipate doing it when we move to be an Eclipse project.

  • The second digit gets updated every major release to the compiler, the Eclipse plugin or any other component we distribute. Minor UI changes to the website or UmpleOnline do not warrant a new release number, however. All components should receive the same new number even if they have not changed. A major release involves substantial change in behaviour, or new features. We will normally do a major release one to four times a year.

  • The third digit is updated when there are bug fixes that invalidate a recent release, but we are not ready to make a change to the second digit. Between major releases we may do this 0-3 times.

  • The remaining components are generated by the build system, and represent an increasing count of commits followed by the git checksum of the commit corresponding to this release, allowing easy location of the release in the git history.

Steps in doing a release

1. Announce intent to do a release in the near future

2. Update Umple with all needed features promised for the release

  • Complete development on planned features, test the features, close the issues

  • Update the compiler, if possible to use the new features.

  • Try to clean out any compiler warning messages.

3. When about to do the release tell people on umple-dev to hold commits for a few hours

  • This will ensure consistent state while doing the release

4. Update the version number and rebuild with the new version number

  • Update and stage for commit the file umpleversion.txt (git add umpleversion.txt) in the build directory. This contains the root of the planned release number (not including the 4th component - the commit number - which we don't know yet).

  • Do a release build using ant -Dmyenv=release . This will ensure that the release number is incorporated into the products built. If this fails saying it can't find a jar with the new release number, then copy the most recent one in dist and give it the name it is looking for starting with the new release code ... this is only temporary) For example cp ../dist/umple- ../dist/umple-

  • Note for the above step if on windows, temporarily change the rake command in the to rake.bat (as in wlocal)

  • Test the release by compiling something and looking at the compiled code to see that it has the new release number. Also run the command-line compiler with --version.

  • Problems can occur at this stage if people have not been careful about committing code. The most common errors relate to code that should say @UMPLE_VERSION@ instead being committed with an actual version number. When the release number changes this can trigger test case failures that will need to be resolved. See DealingWithUMPLE_VERSION for how to deal with any issues. You may need to manually fix the version in UmpleVersion.ump

  • When satisfied with the release, update the version number in umpleversion.last.txt and stage for commit (git add ...)

  • In the dist directory, do 'cp umple-RELEASE.jar libs' (where RELEASE is the new name) this is needed so the next build will work. This needs to be done on the releaser's local machine and also on the server.

  • Run one more time the command ant -Dmyenv=release At this point the release is done; most generated code will still not have the release number on its second line

  • Run a regular full build.

  • SKIP for now. Run a build of the Umplificator:. ant -Dmyenv=local -f build.umple.xml packageUmplificator

  • SKIP for now. Run a build of the Validator:. ant -Dmyenv=local -f build.umple.xml packageValidator

  • SKIP for now. Run a build of the umplificator (cruise.umplificator.X.X.X.jar) plugin: ant -Dmyenv=local -f build.umplificatorplugin.xml

  • Promote the main jars to your UmpleOnline directory ant -DshouldPackageUmpleOnline=true -Dmyenv=local -f build.umple.xml packageUmpleonline

  • Examine changed files to make sure everything is fine. Try running your local copy of UmpleOnline and generating files to ensure that the generating files have the latest release number.

  • do pull request and merge it to finalize.

  • Wait for builds to work to make sure all is OK, and test built version.

5. Upload the newly built files to Github for the release

  • Write some release notes for the Github release (follow the format in previous releases

  • In github create a new release with the tag v.x.x.x based on the actual release number

  • copy the just-built files umple.jar to Github with the new release number in their filenames. Consider doing this for the validator and umplificator.

5. Build the Eclipse plugin update site

6. Ensure scripts on Umpleonline and manual pages are updated.

  • The UmpleOnline UI can be deployed at any time: Instructions are here. But make sure recent changes have been deployed when a release occurs. Note that this is done using the promoteuol script in the bin directory on ralph

7. Update other mirrors such as sourceForge and black duck

  • Load the new jars in SourceForge too

8. Announce the release

At the following: (follow the links from

The following are no longer updated

  • Freecode
Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.