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
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
Close the scala/scala and scala/bug milestones
Point 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.
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). It's better not to release on Friday or before a holiday.
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)
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]
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.13.7 label:release-notes' -q '.items[] | " * \(.title) ([#\(.number)](\(.html_url)) by [@\(.user.login)](\(.user.html_url)))"'
N days before release
Point 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.
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). It's better not to release on Friday or before a holiday.
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
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
before_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=update-api
st_stagingRepoPromote [scala-repo]
,st_stagingRepoPromote [modules-repo]
(or use oss.sonatype.org web UI)Check availability
When everything is on maven central
download/index.md
_config.yml
(update devscalaversion or scalaversion)index.md
(updatecurrentScalaVersion
)api/all.md
,_config.yml
,_overviews/jdk-compatibility/overview.md
current
symlink for the API docs/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]
Modules
Announcements
Afterwards
starr.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 bumplatestSpecVersion
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: