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.com
does 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.com
on 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
.md
formatted 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.