How to release a version of Mirador

Before releasing, ensure that you're on the master branch. Run all tests and ensure that they pass. Also check the continuous integration workflow to make sure tests are passing.

$ npm run test

1. Update the version number in ./package.json. Note: Mirador uses Semantic Versioning to determine version numbers, commit the change, and push it up as a branch. Then, make a pull request for the change to allow for community review of the proposed next version number.

   {
     "name": "mirador",
     "version": "{major}.{minor}.{patch}",
     ...
   }

2. Start drafting GitHub release notes for the tag. Make sure to use the same tag version that was just updated and target the correct branch. Here is a useful template to get started.

   [Commit History](https://github.com/projectmirador/mirador/compare/v3.x.0...v3.x.0) | [Milestone](https://github.com/projectmirador/mirador/issues?q=milestone:{milestone here})
   
   (anything important about this release, themes, etc)
   
   ### New Features and improvements
   
   (#ticketnumber and a human-readable description of the ticket, usually the ticket title. If the ticket title doesn't make sense, either edit the ticket directly, or provide an alternative title here)
   
   ##  Bug Fixes
   
   ### Upgrade Notes
   
   (anything special that needs to be called out)
   

   

3. Create a git tag locally and push it up to GitHub

$ git tag v3.x.x
$ git push origin v3.x.x

1. Release the npm package

   Make sure you are first on the master branch.

   Note: if you are shipping an alpha or beta version, add the appropriate argument

   $ npm login
   # --dry-run to try it out first without actually doing it
   $ npm publish --tag alpha

   If you are shipping a regular version of Mirador, use the following:

   $ npm login
   # --dry-run to try it out first without actually doing it
   $ npm publish

2. Publish the GitHub release

   

3. Send release announcement to Mirador community