github.com/yrj2011/jx-test-infra@v0.0.0-20190529031832-7a2065ee98eb/triage/node_modules/jasmine-core/RELEASE.md (about)

     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 work on feature branches.
    11  
    12  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`.
    13  
    14  ### Version
    15  
    16  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.
    17  
    18  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.
    19  
    20  This version is used by both `jasmine.js` and the `jasmine-core` Ruby gem.
    21  
    22  Note that Jasmine should only use the "patch" version number in the following cases:
    23  
    24  * Changes related to packaging for a specific platform (npm, gem, or pip).
    25  * Fixes for regressions.
    26  
    27  When jasmine-core revs its major or minor version, the binding libraries should also rev to that version.
    28  
    29  ## Release
    30  
    31  When ready to release - specs are all green and the stories are done:
    32  
    33  1. Update the release notes in `release_notes` - use the Anchorman gem to generate the markdown file and edit accordingly
    34  1. Update the version in `package.json` to a release candidate
    35  1. Update any links or top-level landing page for the Github Pages
    36  
    37  ### Build standalone distribution
    38  
    39  1. Build the standalone distribution with `grunt buildStandaloneDist`
    40  
    41  ### Release the Python egg
    42  
    43  Install [twine](https://github.com/pypa/twine)
    44  
    45  1. `python setup.py sdist`
    46  1. `twine upload dist/jasmine-core-<version>.tar.gz` You will need pypi credentials to upload the egg.
    47  
    48  ### Release the Ruby gem
    49  
    50  1. Copy version to the Ruby gem with `grunt build:copyVersionToGem`
    51  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.
    52  1. __NOTE__: You will likely need to push a new jasmine gem with a dependent version right after this release.
    53  1. Push these changes to GitHub and verify that this SHA is green
    54  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.
    55  
    56  ### Release the NPM
    57  
    58  1. `npm adduser` to save your credentials locally
    59  1. `npm publish .` to publish what's in `package.json`
    60  
    61  ### Release the docs
    62  
    63  Probably only need to do this when releasing a minor version, and not a patch version.
    64  
    65  1. `cp -R edge ${version}` to copy the current edge docs to the new version
    66  1. Add a link to the new version in `index.html`
    67  
    68  ### Finally
    69  
    70  1. Visit the [Releases page for Jasmine](https://github.com/jasmine/jasmine/releases), find the tag just pushed.
    71   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.
    72   1. If it is a pre-release, mark it as such.
    73   1. Attach the standalone zipfile
    74  
    75  
    76  There should be a post to Pivotal Labs blog and a tweet to that link.