Release Process¶
The following notes describe how to perform an iMSTK release. Whilst it's not law and doesn't have to be followed precisely, it may provide some useful trip/tricks. Ammend the document as appropriate.
1.) Prep Release¶
- All tests pass
- Check configurations- C# Build
- Norender/renderless Build (for backend usage)
- With/without OpenHaptics, Haply, VRPN
 
- Ensure wrapper generation up to date.- Test failure is not meant to happen if classes aren't wrapped.
 
- Ensure Gitlab Pages are generated from the mirror.- Gitlab Pages (for doxygen code and user documentation) are built on a mirror as gitlab.kitware.comdoes not support Gitlab Pages.
- Ensure Gitlab pipeline passing here (pages job): https://gitlab.com/imstk/imstk.gitlab.io
 
- Gitlab Pages (for doxygen code and user documentation) are built on a mirror as 
- Optional:- Review/Run examples manually.
- Clear warnings as possible.
 
2.) Release Notes¶
Begin the release notes in the .md format for Gitlab and mkdocs.
- Refer to previous releases for formatting.
- Write intro/overview paragraph with focus of improvements.
- Write the shortlog. See separated section below for shortlog generation.
- Write the API changes to the best of your ability. (Easier after creating/reviewing the shortlog.)- If something was renamed, give the new name.
- If something was refactored, give new usage.
- If something was replaced, give the alternative.
 
- Write a thank you & list contributors.- Get list using git shortlog --after="12-1-2018" --summary.
- Include those who worked on the test machine & non MR items that won't show up through git.
 
- Get list using 
3.) Final Commit¶
- Add release notes to the user documentation here
- Iterate version number at the top of root CMakeLists.txt here
- Create the release tag in gitlab.kitware.comon that commit with accompanying release notes.md.
4.) Release Blog¶
- Link the full release notes.- Every major feature should have a longer description with pictures when needed.- Tip: Link to gifs/videos in documentation for better size in blog. Autoplay preferred to capture attention.
 
- Remove minor changes as necessary.
- Add funding acknowledgements.
 
- Every major feature should have a longer description with pictures when needed.
Git Shortlog¶
Note: Do not use a shallow clone. In some cases this may work depending on how far back your history is. Verify you have the full history in git locally.
Note: Grep on git shortlog only works on unix systems. Regex is an alternative, or notepad++ on windows. Or use WSL on windows.
- Find the date of the last release in previous releases. Ex: 12-1-2018
- Use the command:
- Command- This gives .mdformatted hyperlinks for each commit.
- Shortlog is a git feature intended for release notes. It separates commits by author and only displays the commit message. In order by date.
- The command given above is meant to:- Remove commits before that release date.
- Remove merge commits that just say what branch was merged.
- Remove STYLE commits.
- Format with hyperlink.
 
- This requires developers to write good commit messages & separate by type with tags.
 
- This gives 
For example:
- Perform a final trim (the full git log can be lengthy). Remove commits from this log related to the following:- Commits related to minor bugs/refactors
- (auto removed) Commits related to nonfunctional things such as style
- (auto removed) Commits for merges
 
- Cluster and group commits to the best of your ability to reduce size and create a concise list of changes. Keep authors separate to recognize contributions.- If there are 20 commits for one feature, group them under the one head commit. Alter description if needed.
 
- Bugs are tricky, use best judgement on what bugs to report & trim.- For instance a bug introduced in someones MR, shows up as a commit, but is resolved before that branch is even merged. It's not really a bug fix for the release. It was never an issue on imstk-main.