Skip to content

Release Scala 2.13.8 #802

Closed
Closed
@SethTisue

Description

@SethTisue

For every Scala release, make a copy of this file named after the release, and expand the variables.
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.

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):

SCALA_VER_BASE="2.13.8"
SCALA_VER_SUFFIX=""
SCALA_SHA=4b2151cbe4c857d49556b70c3fa0f5e236fd7754
DIST_SHA=b1df74d6534b5d84ace76645fbd08e073a9128d3
SCALA_VER="$SCALA_VER_BASE$SCALA_VER_SUFFIX"

Key links:

N weeks before the release

  • 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!
  • Triage scala/bug and scala/scala-dev tickets
  • 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
  • Create next scala/bug milestone, move pending issues
  • Create next scala/scala-dev milestone, move pending issues
  • Check PRs assigned to the milestone, also check WIP
  • Announce expected release date and current nightly "release candidate" (nightly sha-mangled version) at https://scala-ci.typesafe.com/artifactory/scala-integration/ on https://contributors.scala-lang.org/c/announcements
  • 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)

Release announcement / notes

  • Notify community on https://contributors.scala-lang.org/c/announcements
  • Review merged PRs, make sure release-notes label is applied appropriately
  • PRs with release-notes label must have excellent title & description (title will be pasted literally in release note bullet list)
  • Draft release notes (PR and self-merge, so others can comment there rather than on the commits)
    • Starting point: gh api --paginate -X GET search/issues -f q='repo:scala/scala is:pull-request is:merged milestone:2.12.14 label:release-notes' -q '.items[] | " * \(.title) ([#\(.number)](\(.html_url)) by [@\(.user.login)](\(.user.html_url)))"'
  • On contributors thread, link to release note file and request feedback

N days before release

Point of no return

Once sufficient time for community testing has passed, it's time to cut the release!

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.)

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.)

Check availability

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions