Skip to content

Release 2.12.12 #715

Closed
Closed
@retronym

Description

@retronym

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 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):

  • SCALA_VER_BASE="2.12.12"
  • SCALA_VER_SUFFIX=""
  • SCALA_SHA=cbe6ade1744bb316a63a07b07d3bf448590ad2cd
  • DIST_SHA=2d9200053dad901dbda2789d61057670c2cd757b
  • SCALA_VER="$SCALA_VER_BASE$SCALA_VER_SUFFIX"

Key links:

N weeks before the release

  • 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
  • Announce expected release date and current nightly "release candidate" (nightly sha-mangled version) at https://scala-ci.typesafe.com/artifactory/scala-integration/ on https://contributors.scala-lang.org/c/announcements
  • Also notify Scala Center advisory board members of the upcoming release, so they can help test if they want (Seth can handle this, if asked)

Release announcement / notes

  • Notify community on https://contributors.scala-lang.org/c/announcements
  • Review merged PRs, make sure release-notes label is applied appropriately
  • PRs with release-notes label must have excellent title & description (title will be pasted literally in release note bullet list)
  • Draft release notes (to be published once GitHub tag is pushed)
    • note that GitHub release notes drafts can only be viewed by committers, so use a gist to draft the notes, so the gist can be shared with the community
  • On contributors thread, link to release note gist and request feedback

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.

Check availability

When everything is on maven central

Modules

Announcements

Afterwards

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions