| 1 | # How to work on a Jasmine Release
|
| 2 |
|
| 3 | ## Development
|
| 4 | ___Jasmine Core Maintainers Only___
|
| 5 |
|
| 6 | Follow the instructions in `CONTRIBUTING.md` during development.
|
| 7 |
|
| 8 | ### Git Rules
|
| 9 |
|
| 10 | Please attempt to keep commits to `master` small, but cohesive. If a feature is contained in a bunch of small commits (e.g., it has several wip commits or small work), please squash them when pushing to `master`.
|
| 11 |
|
| 12 | ### Version
|
| 13 |
|
| 14 | We attempt to stick to [Semantic Versioning](http://semver.org/). Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
|
| 15 |
|
| 16 | The current version lives in the file `/package.json`. This version will be the version number that is currently released. When releasing a new version, update `package.json` with the new version and `grunt build:copyVersionToGem` to update the gem version number.
|
| 17 |
|
| 18 | This version is used by both `jasmine.js` and the `jasmine-core` Ruby gem.
|
| 19 |
|
| 20 | Note that Jasmine should only use the "patch" version number in the following cases:
|
| 21 |
|
| 22 | * Changes related to packaging for a specific platform (npm, gem, or pip).
|
| 23 | * Fixes for regressions.
|
| 24 |
|
| 25 | When jasmine-core revs its major or minor version, the binding libraries should also rev to that version.
|
| 26 |
|
| 27 | ## Release
|
| 28 |
|
| 29 | When ready to release - specs are all green and the stories are done:
|
| 30 |
|
| 31 | 1. Update the release notes in `release_notes` - use the Anchorman gem to generate the markdown file and edit accordingly
|
| 32 | 1. Update the version in `package.json` to a release candidate
|
| 33 | 1. Update any links or top-level landing page for the Github Pages
|
| 34 |
|
| 35 | ### Build standalone distribution
|
| 36 |
|
| 37 | 1. Build the standalone distribution with `grunt buildStandaloneDist`
|
| 38 |
|
| 39 | ### Release the Python egg
|
| 40 |
|
| 41 | Install [twine](https://github.com/pypa/twine)
|
| 42 |
|
| 43 | 1. `python setup.py sdist`
|
| 44 | 1. `twine upload dist/jasmine-core-<version>.tar.gz` You will need pypi credentials to upload the egg.
|
| 45 |
|
| 46 | ### Release the Ruby gem
|
| 47 |
|
| 48 | 1. Copy version to the Ruby gem with `grunt build:copyVersionToGem`
|
| 49 | 1. __NOTE__: You will likely need to point to a local jasmine gem in order to run tests locally. _Do not_ push this version of the Gemfile.
|
| 50 | 1. __NOTE__: You will likely need to push a new jasmine gem with a dependent version right after this release.
|
| 51 | 1. Push these changes to GitHub and verify that this SHA is green
|
| 52 | 1. `rake release` - tags the repo with the version, builds the `jasmine-core` gem, pushes the gem to Rubygems.org. In order to release you will have to ensure you have rubygems creds locally.
|
| 53 |
|
| 54 | ### Release the NPM
|
| 55 |
|
| 56 | 1. `npm adduser` to save your credentials locally
|
| 57 | 1. `npm publish .` to publish what's in `package.json`
|
| 58 |
|
| 59 | ### Release the docs
|
| 60 |
|
| 61 | Probably only need to do this when releasing a minor version, and not a patch version.
|
| 62 |
|
| 63 | 1. `cp -R edge ${version}` to copy the current edge docs to the new version
|
| 64 | 1. Add a link to the new version in `index.html`
|
| 65 |
|
| 66 | ### Finally
|
| 67 |
|
| 68 | 1. Visit the [Releases page for Jasmine](https://github.com/jasmine/jasmine/releases), find the tag just pushed.
|
| 69 | 1. Paste in a link to the correct release notes for this release. The link should reference the blob and tag correctly, and the markdown file for the notes.
|
| 70 | 1. If it is a pre-release, mark it as such.
|
| 71 | 1. Attach the standalone zipfile
|
| 72 |
|
| 73 |
|
| 74 | There should be a post to Pivotal Labs blog and a tweet to that link.
|