Releasing

TCLethbridge edited this page Dec 31, 2016 · 9 revisions
Clone this wiki locally

Introduction

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 fourth digit is the commit number of the compiler included in the distribution. Note that this can remain static for periods while the second and third digit change. So, for example, if we release a new version of the Eclipse plugin, but don't release changes to the compiler, then leave the fourth digit untouched. This helps distinguish compatible generated code.

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 and give it the name it is looking for ... this is only temporary)

  • 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 cruise.umple.uottawa.ca 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.

  • Run a build of the Eclipse plugin. ant -f build.eclipseplugin.xml

  • Test the Eclipse plugin by replacing the existing plugin in your plugins directory

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

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

  • 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 the UmpleOnline directory ant -DshouldPackageUmpleOnline=true -Dmyenv=local -f build.umple.xml packageUmpleonline

  • Examine changed files to make sure everything is fine

  • 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

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

  • copy the just-built files umple.jar, and Eclipse plugin jars to Githubwith the new release number in their filenames. Consider doing this for the validator and umplificator.

  • At this stage, announce the release to umple-dev, since everybody should update their environment and load the new Eclipse plugin

6. Update other mirrors such as sourceForge and black duck

  • Load the new jars in SourceForge too

7. Build the Eclipse Update site

8. Deploy any changes to the UmpleOnline UI code if not done prior to the release

  • 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

9. Announce the release

At the following: (follow the links from http://code.umple.org

The following are no longer updated

  • Freecode