Release process

This page is meant for OpenGrok developers.

Semantic versioning

The version string is in the form of x.y.z. If y or x changes, this usually requires reindex from scratch. If only z changes, just redeploy new web application and keep going.

Release criteria

The release process uses continuous integration which means the code base should be ready to release any time.

That said, Ideally, the following minimum criteria should be fulfilled before a new final (i.e. non-prerelease) version is released:

• The overall code coverage must be at least 70%
• Sonarcloud reported bugs should not have any critical issues
• No stoppers (meaning both Issues and Pull requests)
• All bugs and enhancements must be evaluated (for final release also go through issues with given milestone and either fix them or retarget to next release by setting the new milestone)

Process for releasing OpenGrok:

This process is made so that it avoids direct pushes to the master branch.

1. check that latest build passes tests, test code coverage is above given threshold

   If extra care is needed (significant changes since the last release, etc.), consider checking the following:

   • index fairly large code base, ideally multiple projects
   • deploy webapp
   • check UI:
     • history view
       • try comparing 2 distant revisions
       • check pagination
     • annotate view
     • directory listing
       • check sorting using multiple criteria
     • perform search using multiple fields across multiple projects

   The release is OK, once above is fulfilled to our satisfaction.

2. Bump the version by running the release.sh script from the checked out OpenGrok repository:

   ./dev/release.sh INSERT_VERSION_HERE

   This will create new local branch.

   Submit new PR with the changes, wait for the PR to be merged (actually, it should be rebased) into the master branch.

3. Create new release using either Github UI (choose create new tag) or the gh command line tool.

   The release creation automatically adds new Git tag to the repository.

   This will trigger new builds that will build the distribution tarball, Docker image, etc.

4. Go to https://github.com/OpenGrok/OpenGrok/releases and edit the text of the release, e.g. adding list of issues fixed, whether complete reindex is necessary etc.

5. If there was a change in RESTful API, make sure to update the Apiary. Currently this has to be done by hand, because the hooks that performed automatic update had to be removed because of internal policy.