OfficialRelease
When creating an official release for Snowpack, several things must be done, both in term of source code management, documentation and packaging. This Howto should provide a step by step description of what has to be done. First, follow the steps outlined above to compile the necessary components (MeteoIO and Snowpack). Please note that on Windows, there is currently a bug in cmake preventing it from handling properly paths with spaces. So meteoio must be installed to a path that does not contain any spaces in order to be properly detected.
Preparing the source code
- Of course, the warnings should be suppressed (they should never have showed up in the git master) or silenced (for the warnings that have a good reason to stay) on all supported platforms
- Please check that the whole compilation process (including detection of auxiliary components such as MeteoIO) works properly on all platforms
- Update the release number in CMakeLists.txt as well as in snowpack.lsm. The later should also contain the release date.
- Commit any changes you've made
- Check out Snowpack to a fresh location
- Do a default
ccmake .
, enabling "install doc" and "bundle all" - Compile (
make
) and generate the documentation (make doc
)
Compiling
Please follow the steps given for the internal releases, without the packaging that will come after some additional steps.
Preparing the changelog
- Get all the logs since the last release: get the matching git version number from the tags tree, then do a git log --name-only XXX..master > Changelog_full.txt where XXX is the starting git version
- Open the full changelog as well as an empty file side by side.
- Start the new file with something like "This is the changelog for Snowpack release 3.1.0"
- As you go through the full changelog, add items to the new file
- Once you've reached the end of the full changelog, close it and focus on the new changelog
- Try grouping the items you wrote by categories, rephrasing them if necessary. Follow the markdown syntax. You can also edit a previous changelog to copy the style.
- Once this is done, create a new page in the documentation tab of the Snowpack forge. Name it as ChangelogX-X-X with X-X-X being the release number, copy/paste your changelog into it. Check with a preview before committing! (for example, running
mkdocs serve
on the snowpack-web repository) - Link to your new changelog in the Changelogs page
Preparing the documentation
- Obviously, the doxygen documentation must be up to date with the current status of the code. Please also fix all doxygen warnings
- If new graphic files have been prepared, please make sure they show at the proper size in the html and pdf versions
- Commit any changes you've made
Packaging
Please follow the instructions provided on the how to release page.
Distribution on GitLab
Uploading a Generic Package
GitLab offers a Package Registry to publish and share packages. Files can be uploaded as Generic Packages via the GitLab Packages API:
curl --header "PRIVATE-TOKEN: <YOUR_ACCESS_TOKEN>" \
--upload-file <PATH_TO_FILE> \
"https://code.wsl.ch/api/v4/projects/<PROJECT_ID>/packages/generic/<PACKAGE_NAME>/<PACKAGE_VERSION>/<FILE_NAME>?status=default"
Creating or editing a GitLab Release
Next, we can create a Release on GitLab Releases. We press the button "New Release" and select the Tag name that represents our release. After adding a title and some optional release notes, we can link to our packages we created before.
If a release already exists, we can edit it and add our additional links to it.
Further reading
Read more about GitLab Releases in the documentation: GitLab Releases. The specific instructions on how to prepare a release with Subversion (our previous version control system) are kept here.