Skip to content

Dev Maintainers Guide

Jump to bottom
Emily Björk edited this page Jul 3, 2018 · 1 revision

Versioning

This project uses Semantic Versioning for versioning. The major version is only incremented on very large UI changes or when we break compatibility. The minor version is only incremented when new features are added. The patch version is used only for bug fixes. We use the postfix 'rc' to denote release candidates. For example "1.0.0-rc.1".

Branching

Features

Features are developed in branches named feature/myFeature that are based on the develop branch. When the feature is done, it is reviewed and merged into develop.

Releases

The release is developed as features and bug fixes towards the "develop" branch. When the release is feature complete it is branched from "develop" to "release/x.y.z". Any changes to "release/x.y.z" are merged back into develop. When the release is ready, it is merged into "master" and tagged with an annotated tag "x.y.z".

Bug-fixes

A bug-fix or 'patch' release is branched from the tag in master which the bug fix is for and named hotfix/x.y.z. When the hotfix is complete it is merged back into develop to propagate the fix to future versions and also merged into master and tagged as an annotated tag x.y.z.

Building a Release

Checklist

In the branch which the release is made from (release/x.y.z or hotfix/x.y.z) alter:

  • The src/lisong_mechlab/view/LSML.java file so that the VERSION_STRING reads correctly as x.y.z, please notice the leading space, it is intended.
  • The build/LSML Setup.wxs file as to contain a new unique Product ID and also bump the g_version string to be x.y.z.

Building the JAR

Typically you'll build the JAR file from eclipse:

  1. Right click the LSML project and choose Export...
  2. Select Runnable JAR file
  3. Make sure the "Launch configuration" reads: ProgramInit - LSML and "Export destination" reads: LSML\build\lsml.jar, also check that "Library handling" is set to Package required libraries into generated JAR.
  4. Click finish.

Building the installer(s)

We use WiX Toolset for building installers. The .wxs file accepts a parameter "g_64bit" which should be set to "yes" if building a 64bit installer or "no" otherwise. The typical way of building the installers is this:

candle -d"g_64bit"=yes *.wxs
light -ext WixUIExtension *.wixobj
mv "LSML Setup.msi" "LSML Setup-x.y.z (64bit).msi"

candle -d"g_64bit"=no *.wxs
light -ext WixUIExtension *.wixobj
mv "LSML Setup.msi" "LSML Setup-x.y.z (32bit).msi"

Publishing the release

If you are allowed to publish a release, you will have been given access to a shared google drive folder where to put the built .msi installers from the previous step. Update the downloads page on the wiki. More specifically:

  • Update the link to the current version to point to the newly built msi installers
  • Write release notes by reading through all closed issues on the issue tracker for the release.
  • Post the release notes on the MWO forum thread
Clone this wiki locally