Jasmine Core Maintainers Only
Follow the instructions in CONTRIBUTING.md
during development.
Please work on feature branches.
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 merging back to master
.
We attempt to stick to Semantic Versioning. Most of the time, development should be against a new minor version - fixing bugs and adding new features that are backwards compatible.
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.
This version is used by both jasmine.js
and the jasmine-core
Ruby gem.
Note that Jasmine should only use the “patch” version number in the following cases:
When jasmine-core revs its major or minor version, the binding libraries should also rev to that version.
When ready to release - specs are all green and the stories are done:
release_notes
- use the Anchorman gem to generate the markdown file and edit accordinglypackage.json
to a release candidategrunt buildStandaloneDist
Install twine
python setup.py sdist
twine upload dist/jasmine-core-<version>.tar.gz
You will need pypi credentials to upload the egg.grunt build:copyVersionToGem
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.npm adduser
to save your credentials locallynpm publish .
to publish what's in package.json
Probably only need to do this when releasing a minor version, and not a patch version.
cp -R edge ${version}
to copy the current edge docs to the new versionindex.html
There should be a post to Pivotal Labs blog and a tweet to that link.