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 11 installed (Not other major release versions such as JDK 12 or JDK 13).
  • Ensure that the JAVA_HOME environment variable is correctly set to your JDK installation directory. You can refer to the JDK Installation Guide.
  • Ensure that you have merged the upstream master branch into both the local and upstream release branch according to the following steps:
    1. In your local repository, reset your master branch to be exactly the same as the upstream master branch.
    2. Switch to the local release branch, and merge the master branch into it with git merge master --no-ff (no fast forward to keep the commit history for releases).
    3. Push the local release branch directly to the upstream release branch (make sure you have the push access).

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.
    1. Switch to the release branch.
    2. In the terminal, change the directory to the project root directory.
    3. Run gradlew --version to check that the JDK version is 11.
    4. Run gradlew shadowJar, and the Jar file will be generated at {buildDir}/jar/.
    5. 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 https://reposense.org
    • matches the latest released version
    • deployed manually after each new release
  2. Dev website at https://reposense.org/RepoSense
    • matches the latest master branch
    • deployed automatically by Github Actions 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 reposense.org 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 (make sure you have the push access to https://github.com/reposense/reposense.github.io)
  5. After a few minutes, check https://reposense.org to ensure it has been updated as intended.

Hot patching after the release

If critical bugs are found in the release, take the following steps to hot patch it:

  1. Switch to the release branch.
  2. Implement the fixes, commit them, and create a pull request from your forked release branch to the upstream release branch.
  3. After merging, release a new version of RepoSense with the release branch according to the above guide.
  4. Merge the release branch back into the master branch by creating a separate pull request.