Milestone and Release workflow
Scratch is released on a monthly schedule.
A milestone captures the new features and bugs that are expected to be implemented for a particular release. The date associated with a milestone is the date when we freeze the code. When we freeze, we stop merging new changes to allow for testing of the milestone, and to allow for spontaneous singing of the hit song “Let it go”. Following the freeze there is a week or two of testing to make sure everything is ok before we merge the changes into the Master branch. During this time PRs for the next milestone will be left unmerged to allow for testing of the current milestone.
Milestones are shared across many repositories and projects, both public and private.
A release happens when we publish all the changes in a milestone to Scratch, usually a week or so after the freeze date. How long after the freeze exactly depends on how long it takes to test everything, and sometimes external factors – such as a big event, like a Scratch conference – will play a role in deciding exactly when to deploy.
Releases happen across many repositories in the Scratch project, both public and private. Even if all the features and bugs associated with this particular public repository (scratch-www) look ready to go, it won't be released until everything else in our other repositories is ready too.
New and updated strings are pushed to the Transifex server when we freeze the code. When there is a completely new resource (a new page for example), we may manually push the new resource to Transifex ahead of the freeze to give translators a head start. However, the page that uses the strings won't be available until after the release.
Internally we update translations from the Transifex server on a nightly basis. When we build the site for release, the most recent translations will be included. Check out our Localization Guide for more info on that process.
Sometimes it is necessary to release a particular feature on a specific date out of sync from a milestone/release. A hotfix will generally only include the pull requests related to the specific feature/critical bug fix.