Release and hosting information for CanJS maintainers.
For maintainers of CanJS and its submodules this guide describes
- How continuous integration is set up
- How dependencies are kept up to date
- How to make a releases of CanJS subprojects and the main package
All repositories automatically run their tests in Travis CI using the
npm test command (browser tests use Firefox as their target browser). If
npm test is passing locally but not on Travis CI
- Try setting the
DEBUG=testee*environment variable in
travis-ci.org/canjs/<repository>/settingsto get more information.
- Run the tests on an Ubuntu VM (e.g. Ubuntu for Virtualbox)
To view Saucelabs test runs and results, request an invite from a Saucelabs user that has access to the
canjs Saucelabs project (existing users can send invites under my account). Saucelabs tests can be run locally via
npm run ci
Updating dependencies with Greenkeeper
All CanJS repositories are set up with Greenkeeper. Greenkeeper tracks dependencies and creates a branch for every new version coming in. This will trigger Travis CI to run the tests and if a dependency update breaks the tests or a breaking (major) version was released, it will create a pull request.
Greenkeeper is free for open source projects and works on the CanJS organization level. To add a new project or change the status of an existing project:
- Install the command line via
npm install greenkeeper -g
greenkeeper loginto log in via GitHub
- For more information run
- To enable a project, in the project folder run
With the exception of the
can package, ALL subprojects MUST follow the Semantic Versioning guidelines in the form of
MAJORversion when you make incompatible API changes,
MINORversion when you add functionality in a backwards-compatible manner, and
PATCHversion when you make backwards-compatible bug fixes.
Before making any release please make sure that
- You have write access to the GitHub repository you want to publish.
- Have an npm account and are logged in on the CLI tool (
- Your user is a collaborator on npm. You can ask an existing collaborator to add you. Existing collaborators can be listed via
npm owner ls <packagename>or on the npm module page (e.g. can-route).
Releasing CanJS subprojects
All CanJS subprojects modules have the same structure which allows making releases through npm scripts.
To make a release:
Move to the
Fetch all latest changes from the repository
Reinstall all Node modules in their latest version
git checkout master git fetch --all && git rebase npm cache verify rm -rf node_modules npm install
npm run release:<versiontype>. For example, to make a
npm run release:patch
This will run the tests, build, bump the version number accordingly and publish the module to npm.
If you’re already a branch being used for pre-releases, you can run the following to make the next pre-release:
npm run release:pre
If you’re making the first pre-release, you can run one of the following commands, depending on how you need to bump the version:
npm version premajor --preid=pre && npm publish --tag=pre
npm version preminor --preid=pre && npm publish --tag=pre
npm version prepatch --preid=pre && npm publish --tag=pre
Publishing release notes
After you have released the project, you will need to update the release on GitHub. Make sure the newly created tag has been pushed to GitHub (
git push --tags).
Then go to
https://github.com/canjs/<repository>/releases and edit the most recent tag. Give it a title and add any notes or links to issues, then click
Releasing the CanJS main project
The CanJS main project repository is at
canjs/canjs and published as the
can package. We
can module so there is a specified version of the library packages that are
integration tested to work together. A single
can release can include multiple
releases of library packages.
can package does not follow strict semantic versioning
guidelines. It still follows a
MAJOR.MINOR.PATCH release names, but where:
MAJOR- Incompatible API changes in a library in the Core or Infrastructure collection.
can package does follow strict semantic versioning guidelines
with respect to the Core and Infrastructure collections. If a
new Ecosystem or Legacy package is added to
can, it’s treated as a
MINOR changes to
any subsequent releases of those packages are treated as
PATCH changes to
When making a release, review the version number changes and collection of all packages that have changed within the release. Then run
npm run release:<versiontype>.
For example, the following would be a
can-core-a 3.0.1 -> 3.0.2 can-core-b 3.0.1 -> 3.0.10 can-ecosystem-a 1.0.0 -> 2.0.0
The following would be a
can-core-a 3.0.1 -> 3.0.2 can-core-b 3.0.1 -> 3.0.10 // this means can-ecosystem-b was added to the ecosystem collection + can-ecosystem-b 0.0.1
The following would be a
can-core-a 3.0.1 -> 3.0.2 can-core-b 3.0.1 -> 3.1.0 can-ecosystem-a 1.0.0 -> 1.0.1
The following would be a
can-core-a 3.0.1 -> 3.0.2 can-core-b 3.0.1 -> 3.1.0 can-infrastructure-a 3.0.1 -> 4.0.0