Project management

This page contains information about project management tasks. The target audience is senior developers (and above).

Merging PRs

  • Use the 'squash and merge' option unless the situation warrants a different option.
  • For the merge commit, follow conventions at GitHub conventions @SE-EDU.

Making a release on Github

Before making a release, please check the following prerequisites:

  • Ensure that you have JDK 1.8.0 installed (Not other major release versions such as JDK 9 or JDK 11).
  • Ensure that the JAVA_HOME environment variable is correctly set to your JDK installation directory. You can refer to the JDK Installation Guide.

To make a release for RepoSense on Github, please follow the Creating a release section in the Github Docs.

Take note of the following when making the release according to the above guide:

  • When entering a release version number, use semantic versioning with some small tweaks:
    • Use MAJOR.MINOR as the version number when the release includes new features and/or major changes.
    • Use MAJOR.MINOR.PATCH as the version number when the release only includes bug fixes and/or minor changes.
    • Append rc to the version number to indicate that the release is a pre-release that is not ready to be used in production.
  • Enter the release title as RepoSense vxxx where xxx is the version number. Enter the release description by referring to the previous RepoSense releases.
  • Before launching the release, generate the RepoSense.jar file and attach it to the release.
    • Change the directory to the project root directory.
    • In the terminal, run gradlew --version to check that the JDK version is 1.8.0.
    • Run gradlew shadowJar, and the Jar file will be generated at {buildDir}/jar/.
    • Check that the Jar file is working. You may need to check that the report can be generated from the Jar file both locally and remotely by following the Generating Reports Guide.

After making the release, please also remember to deploy the production website using the deploy guide.

Deploying the production website

We have two versions of the website:

  1. Production website at
    • matches the latest released version
    • deployed manually after each new release
  2. Dev website at
    • matches the latest master branch
    • deployed automatically by Travis whenever the master branch is updated

The production website differs from the dev website in some ways, e.g.,

  • It has a CNAME file (to indicate that it is the target destination for the domain name)
  • Its DG pages show a warning that it is not the latest version of the DG.

MarkBind mainly manages these variations via the site.config file. That is why the site.config file in the release branch is slightly different from the one in the master branch.

After each release, do the following steps to deploy the production website:

  1. Switch to the release branch
  2. cd docs
  3. markbind build
  4. markbind deploy
  5. After a few minutes, check to ensure it has been updated as intended.