You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- [ ] On branch `<stable-branch>`, set `baseVersion` to `<stable-version>` and `git tag` it as `<stable-version>`. This will publish artefacts to Sonatype and GitHub Release
15
+
- [ ] Merge branch `<stable-branch>` into `master` to guarantee that all of the `<stable-branch>` commits are propagated to `master`
16
+
- [ ] Look at the milestone of the RC version being released. Move all the open issues from it to the next milestone.
17
+
- [ ] Create branch `<rc-branch>` from `master`
18
+
- [ ] On `<rc-branch>`, set `baseVersion` to `<rc-version>` and `git tag` it as `<rc-version>`. This will publish artefacts to Sonatype and GitHub Release.
19
+
- [ ] On `master`, set `baseVersion` to `<next-version>`
20
+
- [ ] Update `scalaVersion` (and, if applicable, the `sbt-dotty` version) in the Dotty ecosystem projects
Copy file name to clipboardExpand all lines: docs/docs/contributing/release.md
+52-35Lines changed: 52 additions & 35 deletions
Original file line number
Diff line number
Diff line change
@@ -32,42 +32,35 @@ CI is set to automatically detect the tags of the format discussed above and per
32
32
33
33
The CI operation is entirely automatic provided you have tagged the release correctly. No need to do anything here.
34
34
35
+
### Canceling CI builds
36
+
**The below guidelines are needed only to speed up things. It is no mistake if you skip this section. However, if you do things wrong here, there may be trouble. So do it only if you feel yourself confident with the release cycle and the workings of the CI.**
37
+
38
+
Note that after the first stage of the release cycle (see "Publishing artifacts to Maven via CI" section of the checklist below) only three test runs are required to be run at the CI:
39
+
40
+
-`master` branch's latest *commit* with the updated `baseVersion`
41
+
-`<stable-version>`*tag* of the stable version being released
42
+
-`<rc-version>`*tag* of the RC version being released
43
+
44
+
However you may end up with as many as 6 tasks being run. The auxiliary tasks may include:
45
+
46
+
-*commit* tests of the *tags* specified above. You may have two of these, corresponding to the two tags. You should see them appearing to have the same commit hash in the CI, but one of them will have the tag next to it and the other one will not. The *tag* one must remain, as the CI tasks on tags publish to maven. CI tasks on commits do not. So it is safe to cancel the task running on the commit, if the commit hash is the same as that of the tag's task commit.
47
+
- Older commit from the `master` branch. Look for all the tasks run on the `master` branch in the CI and see if there are more than one of these. Then, find the one testing the most recent commit of the branch. The others can safely be canceled.
48
+
35
49
## Documentation
36
50
### Release Procedure Checklist
37
-
Before we start the release procedure, we create an issue with a release checklist. As we go through the release, we update the checklist. In the checklist template below, the following variables are used:
38
-
39
-
-`<stable-version>` is the stable version being released, e.g. `0.14.0`. It is identical to the git tag under which it is released.
40
-
-`<rc-version>` is the version of the RC version being released, e.g. `0.15.0-RC1`. It is identical to the git tag under which it is released.
41
-
-`<stable-branch>` is the name of the stable branch being released, e.g. `0.14.x` if we are releasing `0.14.0`
42
-
-`<rc-branch>` is the RC's branch. E.g. if we are releasing `0.14.0` and `0.15.0-RC1`, the RC version is `0.15.0-RC1`, and `<rc-branch>` is `0.15.x`.
43
-
-`<next-version>` is the tech preview version. It is the next version after the currently released RC. E.g. if we are releasing `0.15.0-RC1`, this variable will be `0.16.0`.
44
-
45
-
A good workflow is to compute these variables before each release, then replace them in the checklist below:
46
-
47
-
```
48
-
- [ ] Publish artifacts to Maven via CI
49
-
- [ ] On branch`<stable-branch>`, set `baseVersion` to `<stable-version>` and `git tag` it as `<stable-version>`. This will publish artefacts to Sonatype and GitHub Release
50
-
- [ ] Merge branch `<stable-branch>` into `master` to guarantee that all of the `<stable-branch>` commits are propagated to `master`
51
-
- [ ] Look at the milestone of the RC version being released. Move all the open issues from it to the next milestone.
52
-
- [ ] Create branch `<rc-branch>` from `master`
53
-
- [ ] On `<rc-branch>`, set `baseVersion` to `<rc-version>` and `git tag` it as `<rc-version>`. This will publish artefacts to Sonatype and GitHub Release.
54
-
- [ ] On `master`, set `baseVersion` to `<next-version>`
55
-
- [ ] Update `scalaVersion` (and, if applicable, the `sbt-dotty` version) in the Dotty ecosystem projects
- [ ] Dotty itself – update the `referenceVersion` in the `master` branch to `<rc-version>`. This is the version of Dotty used to compile the Dotty codebase on `master`.
64
-
- [ ] Scalac CI, like this: scala/scala#7993
65
-
- [ ] Announce the release
66
-
- [ ] Publish releases for the RC and stable versions on GitHub Releases
67
-
- [ ] Publish Blog Post on dotty.epfl.ch
68
-
- [ ] Make an announcement thread on https://contributors.scala-lang.org
69
-
- [ ] Tweet the announcement blog post on https://twitter.com/scala_lang
70
-
```
51
+
Before we start the release procedure, we create an issue with a release checklist. As we go through the release, we update the checklist. To generate the checklist, run the following command:
Above, `<stable_release>` is the stable version being released. For example, if you are releasing `0.14.0` and `0.15.0-RC1`, this variable is `14` and the command is as follows:
The ecosystem update section for some projects also mentions a set of criteria upon which the project is to be marked in the checklist. When the Travis build status is specified next to the project's name, it is to be understood that this build must pass after all of the other criteria of that project are checked. Note that due to caching, the label image next to the link may not reflect the real status of the build. Therefore, to verify the status, click on the link and make sure that your recent commit passes.
62
+
63
+
When no criteria is specified, common sense is to be used.
71
64
72
65
### GitHub Releases and Blog Post
73
66
After the release is done, we document it as follows:
@@ -79,12 +72,36 @@ After the release is done, we document it as follows:
79
72
After releasing a new version of Dotty, we need to make sure to update the following related projects:
- To deploy locally: `git clone https://github.com/lampepfl/dotty-example-project.git && cd dotty-example-project/`
76
+
- To test locally: `sbt run`
77
+
-[Commit](https://github.com/lampepfl/dotty-example-project/commit/76bf0b4d708206b1901fa7f291f07cd470506e79) updating the Dotty version (only `README` and `build.sbt` files)
82
78
-[Example Project with Mill](https://github.com/lampepfl/dotty-example-project/tree/mill)
- Test (note the relative path as argument to `sbt new`, hence this command should be run after Deploy in the same directory as Deploy): `sbt new file://./dotty.g8 --name=foo --description=bar && cd foo && sbt run`
- Deploy: `git clone https://github.com/lampepfl/homebrew-brew.git && cd homebrew-brew`
92
+
-[Commit](https://github.com/lampepfl/homebrew-brew/commit/04f7284564387754a360a354159f2f8d6156a6c7). SHA256 sum comes from the issue checklist computed for the release as specified above. The file with checksums is available at [GitHub Releases](https://github.com/lampepfl/dotty/releases) -> release in question -> assets -> `sha256sum.txt` -> `*.tar.gz` file sum.
86
93
-[Dotty test under various OSs](https://github.com/lampepfl/packtest)
87
-
- 🚫[Scastie](https://github.com/scalacenter/scastie/) – FTTB doesn't work with the new Dotty releases because Scastie uses sbt 0.13.
94
+
- Deploy: `git clone https://github.com/lampepfl/packtest.git && cd packtest`
- Deploy (copy-paste the command and append the release id, e.g. `15` for `0.15.0-RC1`): `git clone https://github.com/scalacenter/scastie.git && cd scastie && git remote add staging https://github.com/dotty-staging/scastie && git checkout -b dotty-release-`<release_id>
98
+
-[PR](https://github.com/scalacenter/scastie/pull/433) – push your changes to `staging` repo (as defined in "Deploy" above) with `git push -u staging`, then submit the PR from there.
0 commit comments