This document describes how Noda Time is released. It is intended to be used as
a checklist by the person doing a release. It only covers doing a
new major/minor release; patch releases are generally just a matter
Build.Directory.props, tagging the right branch and
creating a release in GitHub. The examples given are for releasing 3.1.0.
When everybody's happy, there are no issues outstanding for the milestone, and all the tests pass.
Search the issue tracker for open issues with the right milestone (e.g.
is:open is:issue milestone:1.4.0).
Directory.Build.propsin the root directory; this contains the version number
3.1.0against the new branch
Make changes in the main branch in the nodatime.org repo:
We keep the docfx metadata and snippets for each minor version in the history branch of the nodatime.org repo.
This used to be maintained via a
buildhistory.sh script which would fetch all sources and rebuild from scratch.
As tools have aged, this has become infeasible - but we can easily add new versions.
builddirectory of the nodatime.org repo
rm -rf ./history
for x in tmp/metadata/*/unstable; do cp -r $x history/$(basename $(realpath $x/..))/3.1.x; done
git add --all
unstabledirectory in NodaTime.Web/Markdown to
3.1.x/index.jsonto specify the name
unstabledirectory and copy index.json from
unstable/index.jsonto have a name of
unstableand a parent of
build/docfx/docfx-web.jsonto add the new version
update-3.1.shand edit it accordingly
tzdbupdate/update-all.shto call the new script