Scala 2 team issues. Not for user-facing bugs or directly actionable user-facing improvements. For build/test/infra and for longer-term planning and idea tracking. Our bug tracker is at https://github.com/scala/bug/issues
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):
[x] 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!
[x] Triage scala/bug and scala/scala-dev tickets
[x] 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
[x] Create next scala/bug milestone, move pending issues
[x] Create next scala/scala-dev milestone, move pending issues
[x] Check PRs assigned to the milestone, also check WIP
[x] Check any merged PRs accidentally assigned to the next milestone in this branch, and re-assign them to this milestone
[x] Merge in any older release branch
[x] 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~
[x] Test on Lightbend customer codebase(s), if applicable
[x] 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.
[x] Make sure there are no stray staging repos on Sonatype
[x] Check that JARs haven't mysteriously bloated — compare sizes to previous release. We have no other backstop for this.
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.
[x] Prepare PR to https://github.com/scala/scala-lang/ (using scala/make-release-notes which requires a staged release and a pushed tag; refer to PR from previous release as a guide)
_config.yml (update scalaversion or devscalaversion)
if they don't show up, possible troubleshooting steps include:
review the two scala-dist job logs to make sure that
the first one appears to have succeeded putting files in /home/linuxsoft/archives/scala/api on chara.epfl.ch
the second one appears to have succeeded in updating the symlink (from 2.1x.y to $SCALA_VER)
ssh to chara.epfl.ch and poke around to see if things are where they should be
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 scalatest@chara.epfl.ch
in addition to publishing, PR the addition of the new version to CI and add a patch file so nightlies of the next version work in the community build
Wait for downstream
Before proceeding any further, wait for the ecosystem to catch up.
Downstream publishing:
[x] Wait for Scala.js to support the new release
[x] Wait for Scala Native to support the new release
[x] Wait for scalameta to publish
[x] Wait for scalafix to publish
[x] Wait for Metals to publish
[x] Wait for kind-projector to publish
[x] Wait for scoverage to publish
[x] Wait for scala-debug-adapter to publish
Downstream signoffs:
[x] Ask the Scala Center to sign off (Julien, or Seb)
[x] Ask VirtusLab to sign off (Tomasz, or Krzysztof)
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
[x] On GitHub, use "Create release from tag" button and add release notes
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:
[x] Publish scala-fortify-plugin
[x] Update scala-fortify
[x] Update scala-fortify-docs
[x] (Lightbend) Notify eng-updates
[x] Create a scala/scala PR to:
[x] update starr.version in /versions.properties
[x] update Global / baseVersion in /build.sbt
[x] update mimaReferenceVersion in /project/MimaFilters.scala
[x] clear out mimaFilters in /project/MimaFilters.scala, except the one(s) labeled "KEEP"
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):
Key links:
N weeks before the release
Release announcement / notes
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)))"'N days before release
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.
before_script: export SCALA_VER_BASE=$SCALA_VER_BASE SCALA_VER_SUFFIX=$SCALA_VER_SUFFIXgit tag -s -m "Scala $SCALA_VER" v$SCALA_VER $SCALA_SHAgit tag -s -m "Scala $SCALA_VER" v$SCALA_VER $DIST_SHARelease! (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.
git push https://github.com/scala/scala.git v$SCALA_VERgit push https://github.com/scala/scala-dist.git v$SCALA_VERbefore_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=archives: https://app.travis-ci.com/github/scala/scala-dist/builds/265751302before_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=update-api: https://app.travis-ci.com/github/scala/scala-dist/builds/265751320st_stagingRepoPromote [scala-repo],st_stagingRepoPromote [modules-repo](or use oss.sonatype.org web UI)Check availability
When everything is on maven central
_config.yml(update scalaversion or devscalaversion)_data/scala-releases.yml_downloadsand_posts_config.ymlapi/all.mdoverviews/FAQ/index.mdcontribute/bug-reporting-guide.md_overviews/jdk-compatibility/overview.md(online version: https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html)currentsymlink for the API docs~/home/linuxsoft/archives/scala/apionchara.epfl.ch2.1x.yto $SCALA_VER)ssh jenkins-worker-publish, then from there you canssh -i ~/.ssh/jenkins_lightbend_chara scalatest@chara.epfl.chPrepare downstream
Wait for downstream
Before proceeding any further, wait for the ecosystem to catch up.
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
.zipformat,.tgzdoesn't workcurl -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/releasexxxs with the credential information provided to Seth by Marco Vermeulen (marco at sdkman dot io)sdk list scalaandsdk install scala <version>(these should work immediately once thePOSTsucceeds)PATCHandDELETEare also availablecurl -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/structAfterwards
project/Build.scalacommunity-build/community-projects/stdLib213(after updating https://github.com/dotty-staging/scala to include recent commits)ScalaTarget.scalawill need updatinglatestSpecVersioninspec/_config.ymlon the old branch, so that spec is marked as no longer current~_data/footer.ymland_data/doc-nav-header.ymlon docs.scala-lang.org~starr.versionin/versions.propertiesGlobal / baseVersionin/build.sbtmimaReferenceVersionin/project/MimaFilters.scalamimaFiltersin/project/MimaFilters.scala, except the one(s) labeled "KEEP"spec/_config.yml, if it's a major release~You're done!