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
* lengthen the testing period after a release candidate is chosen
* lengthen the wait time between publishing and announcing
* release on GitHub at announement time, not publishing time
* add steps for downstream projects such as Scala.js, SDKMAN,
Scala Steward, Scalameta, kind-projector, genjavadoc, ...
* require signoff from the Scala Center and VirtusLab
fixes#799
For every Scala release, make a copy of this file named after the release, and expand the variables.
7
-
Ideally this should become a script you can run on your local machine. The only missing piece is programmatic triggering of Travis-CI jobs with custom config.
8
6
9
-
Variables to be expanded in this template (or export them in a local terminal, so that you can copy/paste the commands below without replacing anything):
7
+
Use this template to make a scala-dev ticket named after the release, and fill in the variables.
8
+
9
+
Variables to be expanded in this template (or set and export them in a local terminal, so that you can copy/paste the commands below without replacing anything):
-[ ] Wind down PR queue. There has to be enough time after the last (non-trivial) PR is merged and the next phase. The core of the eco-system needs time to prepare for the final!
28
29
-[ ] Triage scala/bug and scala/scala-dev tickets
29
30
-[ ] Create next scala/scala milestone, move the magical "Merge to 2.13.x" description to it (so Scabot uses it as default for new PRs), move pending PRs
@@ -34,6 +35,7 @@ Key links:
34
35
-[ ] Also notify Scala Center advisory board members of the upcoming release, so they can help test if they want (Seth can handle this, if asked)
35
36
36
37
### Release announcement / notes
38
+
37
39
-[ ] Notify community on https://contributors.scala-lang.org/c/announcements
38
40
-[ ] Review merged PRs, make sure release-notes label is applied appropriately
39
41
-[ ] PRs with release-notes label must have excellent title & description (title will be pasted literally in release note bullet list)
@@ -42,6 +44,7 @@ Key links:
42
44
-[ ] On contributors thread, link to release note file and request feedback
43
45
44
46
### N days before release
47
+
45
48
-[ ] Announce no more PRs will be merged unless last-minute regressions are found. Re-iterate current nightly sha version for testing.
Once sufficient time has passed since last merged PR, it's time to cut the release!
67
+
Once sufficient time for community testing has passed, it's time to cut the release!
65
68
66
-
How long we wait depends on what kind of release it is. For a major release, it might be 1-2 weeks, to give core projects time to try out the preceding release candidate and/or the current candidate nightly. For point releases, assuming we've given the community ahead-of-time warning and kept them appraised of progress on the Discourse thread, and assuming the last changes merged seem sufficiently safe, we might build the next day.
69
+
What is "sufficient" time? A week is a bare minimum. Two weeks is a better "normal" amount. We should also respect requests from Scala Center advisory board members, if they explicitly ask for additional testing time. (In the past, we sometimes only waited a day or two, but this was overly optimistic in presuming that people had been testing nightlies all along.)
67
70
68
-
Be mindful of others' schedules; even minor releases make work downstream (for Scala.js and Scala Native, for the Scala 3 team, for compiler plugin authors, and so on). It's better not to release on Friday or before a holiday.
71
+
Be mindful of others' schedules; even minor releases make work downstream (for Scala.js and Scala Native, for the Scala 3 team, for compiler plugin authors, and so on). And a botched release might make unexpected work for ourselves as well as for others. So it's better not to release on a Friday or even a Thursday, or too close to a major holiday. And it's best to release while everyone in both America and Europe is awake. (First thing in the morning in America is a good choice.)
69
72
70
-
-[ ] Make sure there are no stray [staging repos](https://oss.sonatype.org/#stagingRepositories) on sonatype
73
+
-[ ] Make sure there are no stray [staging repos](https://oss.sonatype.org/#stagingRepositories) on Sonatype
71
74
-[ ] Trigger a custom build on [travis](https://app.travis-ci.com/github/scala/scala)
@@ -84,28 +87,29 @@ Be mindful of others' schedules; even minor releases make work downstream (for S
84
87
-[ ] Check that JARs haven't mysteriously bloated — compare sizes to previous release. We have no other backstop for this.
85
88
- Remember, tags are forever, so are maven artifacts (even staged ones, as they could end up in local caches) and S3 uploads (S3 buckets can be changed, but it can takes days to become consistent)
-[ ] Promote staging repos: `st_stagingRepoPromote [scala-repo]`, `st_stagingRepoPromote [modules-repo]` (or use oss.sonatype.org web UI)
93
96
94
97
### Check availability
98
+
95
99
-[ ] Check release on sonatype: https://oss.sonatype.org/content/repositories/releases/org/scala-lang/scala-compiler/$SCALA_VER/
96
100
-[ ] Check the release on maven central: https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/$SCALA_VER/
97
101
98
102
### When everything is on maven central
103
+
99
104
-[ ] Prepare PR to https://github.com/scala/scala-lang/ (using scala/make-release-notes which requires a staged release and a pushed tag)
100
105
-`download/index.md`
101
106
-`_config.yml` (update devscalaversion or scalaversion)
102
107
-`index.md` (update `currentScalaVersion`)
103
108
-[ ] Prepare PR to https://github.com/scala/docs.scala-lang/
@@ -117,43 +121,75 @@ Be mindful of others' schedules; even minor releases make work downstream (for S
117
121
- if you don't have the credential for this locally but you are able to bring jenkins-worker-publish up at `ssh jenkins-worker-publish`, then from there you can `ssh -i ~/.ssh/jenkins_lightbend_chara [email protected]`
118
122
- see if https://scala-webapps.epfl.ch/jenkins/view/All/job/production_scala-lang.org-scala-dist-archive-sync/ has run a job yet to sync the changes into production
119
123
- if not, you can manually trigger a job. Seth has access to do that, probably others on the team do too. if we get stuck, Fabien can help
120
-
-[ ] Merge the scala-lang PR and the docs.scala-lang.org PR
121
-
-[ ] wait for them to arrive on the websites and make sure they look okay
122
-
- if the scala-lang changes don't show up, possible troubleshooting steps include:
123
-
- see if https://scala-webapps.epfl.ch/jenkins/view/All/job/production_scala-lang.org-builder/ has run a job yet to actually publish the changes
124
-
- see note above about permissions to trigger a job
125
124
126
-
### Modules
125
+
### Prepare downstream
126
+
127
+
-[ ] Create PR to add/update spec links on scala-lang.org (example: https://github.com/scala/scala-lang/pull/1050)
127
128
-[ ] build and release scala-collection-compat and other modules (or open tickets asking that the maintainers do so)
128
129
- this work has moved to https://github.com/scala/make-release-notes/blob/2.13.x/projects-2.13.md
129
130
-[ ] if it's a 2.12.x release, publish macro paradise for the new version
131
+
-[ ] Open a [typelevel/kind-projector](https://github.com/typelevel/kind-projector/issues) ticket requesting publishing
132
+
-[ ] (Lightbend) Open a [lightbend/genjavadoc](https://github.com/lightbend/genjavadoc/issues) ticket requesting publishing (the Akka team usually does it)
-[ ] add a reply on the same https://contributors.scala-lang.org thread where you announced that the release process was starting
134
164
-[ ] Tweet from [@scala_lang](https://twitter.com/scala_lang)
135
-
-[ ]https://gitter.im/scala/scala
136
-
-[ ] if you feel like it, say something in https://gitter.im/scala/contributors too
137
-
-[ ] Discord in addition, or instead?
165
+
-[ ] Discord: link to release notes in #announcements channel
166
+
-[ ] consider also saying something in #scala-contributors channel
167
+
-[ ] Unblock the release in Scala Steward by PRing an update to [default.scala-steward.conf](https://github.com/scala-steward-org/scala-steward/blob/master/modules/core/src/main/resources/default.scala-steward.conf)
168
+
-[ ] Ensure SDKMAN makes the release available (see scala/scala-dev#782)
138
169
-[ ] ask Seth to announce on #scala IRC
139
170
140
171
### Afterwards
141
-
-[ ] Check the release on maven search (may take a few hours):
-[ ] Create PR to add/update spec links on scala-lang.org (example: https://github.com/scala/scala-lang/pull/1050)
172
+
173
+
-[ ] Scastie: open PR adding new version (modeled on https://github.com/scalacenter/scastie/pull/538)
174
+
- note that the PR won't be mergeable until kind-projector has published; and if kind-projector's version number has changed, `ScalaTarget.scala` will need updating
175
+
-~If it's a major release:~
176
+
-~Update `latestSpecVersion` in `spec/_config.yml` on the old branch, so that spec is marked as no longer current~
177
+
-~Ditto for the nightly build and spec links in `_data/footer.yml` and `_data/doc-nav-header.yml` on docs.scala-lang.org~
178
+
-[ ] Create PR to update https://github.com/lightbend/lightbend-technology-intro-doc/blob/master/docs/modules/getting-help/pages/build-dependencies.adoc
179
+
- (Lightbend) Fortify:
180
+
-[ ] Publish scala-fortify-plugin
181
+
-[ ] Update scala-fortify
182
+
-[ ] Update scala-fortify-docs
183
+
-[ ] (Lightbend) Update whatever we replaced WhiteSource with, if anything?
0 commit comments