Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Scala 2.12.20 #871

Closed
90 of 91 tasks
SethTisue opened this issue Aug 8, 2024 · 1 comment
Closed
90 of 91 tasks

Release Scala 2.12.20 #871

SethTisue opened this issue Aug 8, 2024 · 1 comment
Assignees
Milestone

Comments

@SethTisue
Copy link
Member

SethTisue commented Aug 8, 2024

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

SCALA_VER_BASE="2.12.20"
SCALA_VER_SUFFIX=""
SCALA_SHA=13f19f4d5f9c036019b671a53a788bbaed67adf8
DIST_SHA=b1736d788522fb4c566db732867c7a6c2990c455
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)
    • (for 2.12.20, waiting until I can tell them about 2.13.15 at the same time)

Release announcement / notes

  • 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

  • Announce no more PRs will be merged unless last-minute regressions are found. Re-iterate current nightly sha version for testing.
  • Community build green on JDK 8, 11, 17, 21, 23
  • Windows build on GitHub Actions: https://github.com/scala/scala/actions/runs/10414683442
  • JDK 17 build on Travis-CI (cron job): https://app.travis-ci.com/github/scala/scala/builds/271912860
  • Check any merged PRs accidentally assigned to the next milestone in this branch, and re-assign them to this milestone
  • Merge in any older release branch
  • Check module versioning (is everything in versions.properties up to date?)
    • including make sure the version of scala-asm we're using is using latest ASM
  • On major release, bump PickleFormat version
  • Test on Lightbend customer codebase(s), if applicable
  • Close the scala/scala and scala/bug milestones

Allow time for testing

How much time is sufficient? 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.)

Stage! (point of soft no-return)

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

We call this "soft" no-return because even staged artifacts can end up in local caches and cause confusion.

Release! (point of hard no-return)

"Hard" no-return because Maven Central is forever. Also, S3 uploads should be treated as forever (S3 buckets can be changed, but it can takes days to become consistent). Tags, too, should be treated as forever, even though they can technically be deleted and re-pushed.

While waiting for Maven Central

Find the release on Maven Central

After everything is on Maven Central

Prepare downstream

Wait for downstream

Before proceeding any further, wait for the ecosystem to catch up.

  • Downstream publishing:
    • Wait for Scala.js to support the new release
    • Wait for Scala Native to support the new release
    • Wait for scalameta to publish
    • Wait for scalafix to publish
    • Wait for Metals to publish
    • Wait for kind-projector to publish
    • Wait for scoverage to publish
  • Downstream signoffs:
    • Ask the Scala Center to sign off (Seb)
    • Ask VirtusLab to sign off (Tomasz)

We have promised to wait 48 non-weekend hours, minimum.

If there are delays downstream, at some point it may make sense to go ahead and announce anyway, since news of the release will already be spreading in the community.

Announcements

  • On GitHub, use "Create release from tag" button and add release notes
  • Merge the scala-lang PR and the docs.scala-lang.org PR
  • Scala Users discourse https://users.scala-lang.org
  • Announce on Twitter from @scala_lang
  • Announce on Mastodon from @scala_lang
    • Seth has the login info for Twitter and Mastodon. Upstream contact is Toli.
  • Discord: link to release notes in #links channel
    • consider also saying something in #scala-contributors channel
  • Unblock the release in Scala Steward by PRing an update to default.scala-steward.conf
  • Add the release to SDKMAN
    • as per the documentation at https://sdkman.io/vendors
    • URL provided must be in .zip format, .tgz doesn't work
    • sample command: curl -X POST -H "Consumer-Key: xxx" -H "Consumer-Token: xxx" -H "Content-Type: application/json" -H "Accept: application/json" -d '{"candidate": "scala", "version": "2.13.9", "url": "https://downloads.lightbend.com/scala/2.13.9/scala-2.13.9.zip"}' https://vendors.sdkman.io/release
    • replace both xxxs with the credential information provided to Seth by Marco Vermeulen (marco at sdkman dot io)
    • test afterwards with sdk list scala and sdk install scala <version> (these should work immediately once the POST succeeds)
    • to correct mistakes, PATCH and DELETE are also available
    • broadcast the addition via the SDKMAN twitter account
      • sample command: curl -X POST -H "Consumer-Key: xxx" -H "Consumer-Token: xxx" -H "Content-Type: application/json" -H "Accept: application/json" -d '{"candidate": "scala", "version": "2.13.9", "url": "https://github.com/scala/scala/releases/tag/v2.13.9"}' https://vendors.sdkman.io/announce/struct
      • make sure it shows up at https://twitter.com/sdkman_
  • Announce on https://reddit.com/r/scala
  • ask Seth to announce on #scala IRC

Afterwards

  • sbt: if it's a 2.12.x release, open PR updating version
  • Scala 3: open PR updating version:
  • Scastie: open PR adding new version (modeled on Add support for Scala 2.13.7 scalacenter/scastie#538)
    • 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
  • If it's a major release:
    • Update latestSpecVersion in spec/_config.yml on the old branch, so that spec is marked as no longer current
    • Ditto for the nightly build and spec links in _data/footer.yml and _data/doc-nav-header.yml on docs.scala-lang.org
  • (Lightbend) Fortify:
    • Publish scala-fortify-plugin
    • Update scala-fortify
    • Update scala-fortify-docs
  • (Lightbend) Notify eng-updates
  • Create a scala/scala PR to:
    • update starr.version in /versions.properties
    • update Global / baseVersion in /build.sbt
    • update mimaReferenceVersion in /project/MimaFilters.scala
    • clear out mimaFilters in /project/MimaFilters.scala, except the one(s) labeled "KEEP"
    • spec/_config.yml, if it's a major release
  • Once that PR is merged and a new nightly has published, ./advance scala (and PR it) in the community build
  • Update https://contributors.scala-lang.org thread
  • Create https://contributors.scala-lang.org thread for the next release

You're done!

  • Close this ticket and close the scala-dev milestone
@SethTisue SethTisue self-assigned this Aug 8, 2024
@SethTisue SethTisue added this to the 2.12.20 milestone Aug 8, 2024
@SethTisue
Copy link
Member Author

"notify eng-updates" is the only unchecked box; I'll do that for 2.12.20 and 2.13.15 together

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant