Release process

1. Verify behavior and test for regressions

Prior to publishing your new dygraphs version, you should test it locally. There are two repositories that will help you verify dygraphs' behavior and test for regressions:

dygraphs-es6 can be a help when running a manual smoke test.

git clone [email protected]:danvk/dygraphs-es6.git
cd dygraphs-es6
npm install
npm install path/to/dygraphs/directory
./node_modules/.bin/webpack
open index.html

When the page loads, you should see a graph rendered on the screen.

dygraphs-dpxdt can be a help when checking for regressions.

This project runs a series of tests and captures screenshots for each test case. You can run the suite once on one dygraphs version, and then run it again on a second dygraphs version. Comparing the screenshots should reveal any minor regressions that you otherwise wouldn't have noticed.

git clone [email protected]:danvk/dygraphs-dpxdt.git
cd dygraphs-dpxdt
pip install dpxdt
dpxdt update .
git diff

If the screenshots are different, git will report a difference in the respective binary file. If you'd like to inspect the difference visually, you can use a tool like git webdiff.

Note: For this to work, it's required that the dygraphs is a sibling of the dygraphs-dpxdt. Note: Default font family and size may differ between machines, so it's best practice to git commit the screenshots from version A before running the suite against version B.

2. Bump version strings and add release notes

Note: During this process, you may notice some untracked files (e.g. in /src-es5). Be sure not to include and commit these files when you run through the following:

git checkout master
git pull
# add a new section in releases.json
# update version in package.json
# update version in dygraph.js
# add a new section in docs/versions.html, including major changelog entries
git commit -a -m 'Bump versions and add release notes'
git push

3. Draft a GitHub Release

Navigate to the releases page of the dygraphs repository and draft a new release. Take the version string that you've committed in the files above, and use the formatted version (with a v in front, e.g. v2.1.0) for both the Tag version and the Release title. Use the description section to write a summary of the changes in this release, including New features, Bug fixes, Internal refactors/fixes, etc. Feel free to use the description markdown from a previous release as a guide. When finished, press Publish release. Keep in mind that you can make changes to this release later if there are mistakes to correct.

4. Publish NPM Package

Note: When pushing code to GitHub, we intentionally exclude files that are generated during an npm run build, as it can be a pain to keep these files in sync without merge conflicts. However, we do want these files to be present while we publish a new build to NPM. If they are missing at the time of a publish, NPM will receive an incomplete package, and you will have to bump the version string again to publish again.

git checkout master
git pull
npm install
npm run build

# Verify the presence of the `dist/` and `src-es5/` directories.
ls

npm publish

5. Verification

• Verify that the NPM listing has the newest release.

• Use the dygraphs-es6 project mentioned above to validate your new build. Install your new dygraphs version (e.g. 2.1.0) and open index.html:

cd dygraphs-es6
npm install [email protected]
./node_modules/.bin/webpack
open index.html

• Verify that cdnjs has picked up the change. This might take up to ~15min.

6. Update dygraphs.com

To push your new version (e.g. 2.1.0), you'll want to update the root path as well as the path specific to your version:

./scripts/push-to-web.sh [email protected]:dygraphs.com/2.1.0
./scripts/push-to-web.sh [email protected]:dygraphs.com

Note: Both of these commands are password-protected.

7. Notify Dygraphs Users

• Make a release announcement in the Google Group