digital-asset/daml
1
1
Fork 0
mirror of https://github.com/digital-asset/daml.git synced 2024-09-20 09:17:43 +03:00
Code Issues Projects Releases Wiki Activity
59f480d978
daml/release/RELEASE.md

30 lines
1.6 KiB
Markdown
Raw Normal View History

Document release process
2019-04-04 12:55:22 +03:00
# Making a Release
prepare release note for next release (#443)
2019-04-12 17:17:31 +03:00
1. Update https://github.com/digital-asset/daml/docs/source/support/release-notes.rst
Update Readme.md with instructions for release notes
2019-04-04 15:14:17 +03:00
by adding a new header for the new version above any changes since the last
version.
Change all list numbers to 1s in Readme.md
2019-04-04 15:40:20 +03:00
1. Make a PR that only bumps the version number in the VERSION
Document release process
2019-04-04 12:55:22 +03:00
file. It is important that the PR only changes the VERSION file.
push releases to github (#413) Azure Pipelines has direct integration with GitHub, so we're just using that. Releases on GitHub have to target a tag, so we also need to push the tag as an intermediate step; we also need to include the platform name in the artifact to avoid overwriting from different builds. The two "GitHub release" steps depend on two Azure variables that are not defined in the pipeline script. This may look like it should not work, but in fact it does, because these variables are set by the release script. In Azure Pipelines, any build step can set variables for the next build steps by outputting specially-formatted text to stdout. This text will not appear in the build output displayed by Azure Pipelines, e.g.: ``` echo '##vso[task.setvariable variable=sauce]tomatoes' ``` would define the Azure variable `sauce` to have the string `tomatoes` as its value for the next build steps. See [0] for details. [0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#set-in-script
2019-04-12 13:30:13 +03:00
1. Squash the PR.
1. Once CI has passed for the corresponding master build, the release should be
available on bintray and GitHub, as well as properly tagged.
Change all list numbers to 1s in Readme.md
2019-04-04 15:40:20 +03:00
1. Activate the new version with `da use VERSION`. Note that it will
Document release process
2019-04-04 12:55:22 +03:00
not be picked up by `da upgrade` at this point.
Change all list numbers to 1s in Readme.md
2019-04-04 15:40:20 +03:00
1. Run through the manual test plan described in https://docs.google.com/document/d/16amcy7bQodXSHjEmKhAUiaPf6O92gUbch1OyixDEvSM/edit?ts=5ca5be00.
push releases to github (#413) Azure Pipelines has direct integration with GitHub, so we're just using that. Releases on GitHub have to target a tag, so we also need to push the tag as an intermediate step; we also need to include the platform name in the artifact to avoid overwriting from different builds. The two "GitHub release" steps depend on two Azure variables that are not defined in the pipeline script. This may look like it should not work, but in fact it does, because these variables are set by the release script. In Azure Pipelines, any build step can set variables for the next build steps by outputting specially-formatted text to stdout. This text will not appear in the build output displayed by Azure Pipelines, e.g.: ``` echo '##vso[task.setvariable variable=sauce]tomatoes' ``` would define the Azure variable `sauce` to have the string `tomatoes` as its value for the next build steps. See [0] for details. [0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#set-in-script
2019-04-12 13:30:13 +03:00
1. If it passes, the release should be made public. This currently
consists of two steps:
Document release process
2019-04-04 12:55:22 +03:00
1. Tag the release as `visible-external` on Bintray. This step can
only be done by someone with permissions to set tags on Bintray.
After this step the release will be picked up by `da upgrade`.
Change all list numbers to 1s in Readme.md
2019-04-04 15:40:20 +03:00
1. Trigger the CircleCI jobs to create the Docker images. To do so,
Document release process
2019-04-04 12:55:22 +03:00
go to
https://circleci.com/gh/DACH-NY/workflows/damlc-docker/tree/master
and click "rerun" on "master / Main Variant" and on "master / CircleCI Variant".
Once the jobs have passed, you should see two new images on https://hub.docker.com/r/digitalasset/daml-sdk/tags.
require manual publication of GitHub releases (#435) Because automated testing is not yet part of our release pipeline, we need to manually publish releases after manual testing.
2019-04-12 15:15:19 +03:00
1. Publish the draft release on GitHub by going to [the releases
page](https://github.com/digital-asset/daml/releases) and clicking the
Edit button for the relevant release.
Reference in New Issue Copy Permalink