RELEASE.md

Ember.js Releases

Concepts

• 6-week release cycle
  • weekly beta
• Channels
  • Release (stable)
  • Beta
  • Canary
• SemVer
  • Patch
  • Minor (point)
  • Major

---

Ember Notes on Point Releases (Not Release Notes)

1. Check out beta branch and git pull
2. Make sure any master commits that are conceptually [{BUGFIX,DOC} {beta,release}] are cherry-picked.
3. git push origin beta, and let travisBranch = kick off a travis build
4. PRIOR_VERSION=v2.5.0-beta.1 ./bin/changelog | uniq | pbcopy
5. Open CHANGELOG.md, paste in the results of the previous script, and clean it up for human-readability.
   1. e.g. [BUGFIX beta] -> [BUGFIX], [DEPRECATE beta] -> [DEPRECATE], ...
   2. Revert [BUGFIX ...] -> [BUGFIX] Revert ...
   3. rm [DOC] (usually)
   4. rm other trivial things
6. Backport CHANGELOG to master
7. await travisBranch
   1. if travis succeeds, process
   2. if travis fails and it's a fix that doesn't need to be on master (e.g. linting or merge conflicts accidentally checked in), fix and retry.
   3. otherwise, start over
8. Update package.json and VERSION file to use new version number
9. git add/commit -m "Release v2.5.0-beta.2."
10. git tag v2.5.0-beta.2
11. git push origin v2.5.0-beta.2, and let travisTag = kick off a travis build (to produce the assets)
12. git push origin beta
13. git checkout beta
14. rm -rf dist && mkdir dist && cp ../components-ember/* dist/
15. Go to https://github.com/emberjs/ember.js/releases
16. Click on the most recent tag (2.5.0-beta.2), and then click "Edit"
17. Start with ### Changelog and copy/paste the changelog into the box
18. Make the title Ember 2.5.0-beta.2 and check "This is a prerelease" for betas
19. Update builds page
20. Deploy

---

Ember Notes on Release (Not Release Notes)

Starting point: https://gist.github.com/rwjblue/fb945e55c70d698d4074

LTS Releases

1. In Ember bower repo, git co -b lts-2-4 , git push origin
2. In bin/publish_to_s3.js and bin/bower_ember_build, add relevant "lts-2-4" lines (see https://github.com/emberjs/ember.js/commit/618de4fa036ab33dc760343decd355ede7b822bb)
3. Follow usual stable point-release steps (release the LTS as 2.4.${++latest})

Stable Release

Review Commits

1. Ensure that all commits that are tagged for release are in the release.
2. Review commits by hand since last beta was cut.
4. You may run into trouble since commits are at canary, but release is from a branch 6 weeks ago
5. @rwjblue: I have a changelog generator script that correctly links commits to PRs
   1. It looks at all commits on beta branch, finds the original commit where that come from, and finds the originating PR
6. If I happen to run that tool again, it tells me that I have already run it so I don't accidentally run it twice
7. @rwjblue: I manually scan commits looking for "bugfix beta" and cherry-pick them into the beta branch (which is imminently becoming the release branch)
   1. Automating "look for bugfix beta commits since last beta release" seems like an easy win (@tomdale)

Build Changelog

1. Push beta branch to get Travis to run
2. Run PRIOR_VERSION=<tag> ./bin/changelog | uniq | pbcopy
3. Clean up commits in CHANGELOG
   1. e.g. [BUGFIX beta] -> [BUGFIX], [DEPRECATE beta] -> [DEPRECATE], ...
   2. Remove [DOC] changes (who cares)
   3. Improve formatting (you're now in a Markdown document, so wrap code in ``s.
4. Collapse all "beta" sections into final release
   1. E.g., commits from "beta.1", "beta.2", "beta.3" should just go under "2.4.0" or whatever
5. Commit CHANGELOG

Bump Version

1. Edit package.json to correct version (2.4.0)
2. Edit VERSION file to correct value
   1. Seems easy to automate fixing this. Replace reading VERSION with reading package.json so you only have to change it in one place
3. Commit package.json/version tags
4. Add commit message: "Release v2.4.0"
5. git tag v2.4.0

Release

1. git push origin v2.4.0 to push JUST the tag. This lets us run the tag first on Travis CI, which does the correct deploy to S3, Bower, etc.
2. THEN wait for Travis CI build to finish
3. Go to github and disable branch protection for the release branch
4. Backup the current release branch: git push origin release:release-version
5. To make this the current release branch: git push -f origin beta:release
   1. This promotes the beta branch on your machine (that has all of the release commits) the new release branch on origin
6. If you are paranoid like rojax, "freeze" this version of Ember in amber: mv ember-beta ember-release-v2.4
7. Go to github and enable branch protection for the release branch

Add Release on GitHub

1. Go to GitHub and add a new release
2. Add title: Ember 2.4
3. Copy and paste CHANGELOG

# generate-api-docs.rb
require 'yaml'

data = YAML.load_file("../components-ember/ember-docs.json")
data["project"]["sha"] = ENV['VERSION']

File.open("data/api.yml", "w") do |f|
  YAML.dump(data, f)
end

On to the Beta Release…

1. Check out master branch and pull to get latest canary on your local machine
2. nombom and run those tests!
3. Branch locally to beta
   1. git checkout -b beta
4. Manually disable features
   1. Change everything in packages/@ember/canary-features.ts's DEFAULT_FEATURES export from null to false to ensure they are stripped
   2. Any feature that has been GOed gets changed to true
5. Run ember s -prod
6. Run tests at http://localhost:4200/tests/index.html
7. Run production tests http://localhost:4200/tests/index.htmlskipPackage=container,ember-testing,@ember/debug&dist=prod&prod=true
8. In .travis.yml, remove branches: section e.g. this commit.
9. Now we have to look at the commit just prior to branching 2.4.0.beta-1. Then find the commit after that to start the new branch at.

Changelog

1. PRIOR_VERSION=v2.4.0-beta.1^ HEAD=master ./bin/changelog | uniq | pbcopy
2. Clean up changelog. Make sure the changelog from the stable release you just did is included.

Tag & Release

1. Update package.json and VERSION file to use new version number
2. git tag v2.5.0-beta.1
3. git push origin v2.5.0-beta.1
4. git push -f origin beta:beta