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
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
Once sufficient time has passed since last merged PR, it's time to cut the release!
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.
Make sure there are no stray staging repos on sonatype
Check that JARs haven't mysteriously bloated — compare sizes to previous release. We have no other backstop for this.
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)
Uh oh!
There was an error while loading. Please reload this page.
Key links:
N weeks before the release
Release announcement / notes
N days before release
testAll
) on JDK 11 and 15Upgrade to JLine 3.17.1 scala#9294On major release, bump PickleFormat versionPoint of no return
Once sufficient time has passed since last merged PR, it's time to cut the release!
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.
before_script: export SCALA_VER_BASE=2.13.4 SCALA_VER_SUFFIX=""
git tag -s -m "Scala 2.13.4" v2.13.4 39148e4ec34a5c53443dd1b25ceec2308cd097fe
git tag -s -m "Scala 2.13.4" v2.13.4 4218dfc75b9e2a5310b7abde28d3d6ba8e611601
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://travis-ci.org/github/scala/scala-dist/builds/744628712before_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=update-api
: https://travis-ci.org/github/scala/scala-dist/builds/744628790st_stagingRepoPromote [scala-repo]
,st_stagingRepoPromote [modules-repo]
(or use oss.sonatype.org web UI)Check availability
When everything is on maven central
documentation/api.md
download/index.md
_config.yml
(update devscalaversion or scalaversion)api/all.md
,_config.yml
On 2.13.0 only: (manually) update thecurrent
symlink for the API docsModules
build and release scala-collection-compat and other modules (or open tickets asking that the maintainers do so)if it's a 2.12.x release, publish macro paradise for the new versionAnnouncements
Afterwards
Create PR to add/update spec links on scala-lang.org(example: update spec links and advisements scala-lang#1050)versions.properties
and thebaseVersion
inbuild.sbt
.spec/_config.yml
.latestSpecVersion
inspec/_config.yml
on the old branch, so that spec is marked as no longer current_data/footer.yml
and_data/doc-nav-header.yml
on docs.scala-lang.orgThe text was updated successfully, but these errors were encountered: