-
Notifications
You must be signed in to change notification settings - Fork 14
Release Scala 2.13.8 #802
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
Milestone
Comments
When everything is on maven central
Prepare downstream
|
Wait for downstreamBefore 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
Afterwards
You're done!
|
Everything's done except SDKMAN; pursuing that at #782 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For every Scala release, make a copy of this file named after the release, and expand the variables.
Ideally this should become a script you can run on your local machine. The only missing piece is programmatic triggering of Travis-CI jobs with custom config.
Variables to be expanded in this template (or 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
Point of no return
Once sufficient time for community testing has passed, it's time to cut the release!
What is "sufficient" time? 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.)
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
: https://app.travis-ci.com/github/scala/scala-dist/builds/244556354before_script: export version=$SCALA_VER scala_sha=$SCALA_SHA mode=update-api
: https://app.travis-ci.com/github/scala/scala-dist/builds/244556405st_stagingRepoPromote [scala-repo]
,st_stagingRepoPromote [modules-repo]
(or use oss.sonatype.org web UI)Check availability
The text was updated successfully, but these errors were encountered: