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
Use this template to make a scala-dev ticket named after the release, and fill in the variables.
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!
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
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.
Make sure there are no stray staging repos on Sonatype
If you get "Server redirected too many times" from Sonatype, you may need to redo the Travis-CI secrets as per Release 2.12.15 #783 (comment) -- this seems to reoccur from time to time for unknown reasons
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.
Promote staging repos: st_stagingRepoPromote [scala-repo], st_stagingRepoPromote [modules-repo] (or use oss.sonatype.org web UI)
While waiting for Maven Central
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 [email protected]
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:
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
Wait for scala-debug-adapter 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
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
Use this template to make a scala-dev ticket named after the release, and fill in the variables.
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
On major release, bump PickleFormat versionAllow 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_SUFFIX
git tag -s -m "Scala $SCALA_VER" v$SCALA_VER $SCALA_SHA
git tag -s -m "Scala $SCALA_VER" v$SCALA_VER $DIST_SHA
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.
git push https://github.com/scala/scala.git v$SCALA_VER
git push https://github.com/scala/scala-dist.git v$SCALA_VER
before_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=archives
: https://app.travis-ci.com/github/scala/scala-dist/builds/?before_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=update-api
: https://app.travis-ci.com/github/scala/scala-dist/builds/?st_stagingRepoPromote [scala-repo]
,st_stagingRepoPromote [modules-repo]
(or use oss.sonatype.org web UI)While waiting for Maven Central
_config.yml
(update scalaversion or devscalaversion)_data/scala-releases.yml
_downloads
and_posts
-
_config.yml
api/all.md
overviews/FAQ/index.md
contribute/bug-reporting-guide.md
_overviews/jdk-compatibility/overview.md
(online version: https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html)Find the release on Maven Central
After everything is on Maven Central
On major releases only: (manually) update thecurrent
symlink for the API docshttps://github.com/scala/scala-dist/blob/2.13.x/scripts/jobs/release/website/update-api#L15/home/linuxsoft/archives/scala/api
onchara.epfl.ch
2.1x.y
to $SCALA_VER)ssh jenkins-worker-publish
, then from there you canssh -i ~/.ssh/jenkins_lightbend_chara [email protected]
Prepare downstream
Create PR to add/update spec links on scala-lang.org (example: update spec links and advisements scala-lang#1050)build and release scala-collection-compat and other modules (or open tickets asking that the maintainers do so)this work has moved to https://github.com/scala/make-release-notes/blob/2.13.x/projects-2.13.mdWait 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
.zip
format,.tgz
doesn'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/release
xxx
s with the credential information provided to Seth by Marco Vermeulen (marco at sdkman dot io)sdk list scala
andsdk install scala <version>
(these should work immediately once thePOST
succeeds)PATCH
andDELETE
are 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/struct
Afterwards
project/Build.scala
community-build/community-projects/stdLib213
(after updating https://github.com/dotty-staging/scala to include recent commits)ScalaTarget.scala
will need updatingIf it's a major release:UpdatelatestSpecVersion
inspec/_config.yml
on the old branch, so that spec is marked as no longer currentDitto for the nightly build and spec links in_data/footer.yml
and_data/doc-nav-header.yml
on docs.scala-lang.orgstarr.version
in/versions.properties
Global / baseVersion
in/build.sbt
mimaReferenceVersion
in/project/MimaFilters.scala
mimaFilters
in/project/MimaFilters.scala
, except the one(s) labeled "KEEP"spec/_config.yml
, if it's a major release./advance scala
(and PR it) in the community buildYou're done!
The text was updated successfully, but these errors were encountered: