Bitovi

Releasing CanJS

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

Continuous Integration

Travis CI

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>/settings to get more information.
Run the tests on an Ubuntu VM (e.g. Ubuntu for Virtualbox)

Saucelabs

canjs/canjs also runs the tests of all dependencies in the supported browsers on Saucelabs:

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
Run greenkeeper login to log in via GitHub
For more information run greenkeeper or greenkeeper start
To enable a project, in the project folder run greenkeeper enable

Making releases

With the exception of the can package, ALL subprojects MUST follow the Semantic Versioning guidelines in the form of MAJOR.MINOR.PATCH for

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version 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 (npm whoami).
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 master branch
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 clean
rm -rf node_modules
npm install

Then run npm run release:<versiontype>. For example, to make a PATCH release:
```
npm run release:patch
```

This will run the tests, build, bump the version number accordingly and publish the module to npm.

Releasing the CanJS main project

The CanJS main project repository is at canjs/canjs and published as the can package. We publish a 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.

The 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.
MINOR - Either:
- New features added Core and Infrastructure but still backwards-compatible.
- New Ecosystem or Legacy library added or removed to their respective collection.
PATCH - Either:
- Bug fixes in Core and Infrastructure.
- A new release of a Ecosystem or Legacy library.

The 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 can, any subsequent releases of those packages are treated as PATCH changes to can.

When making a release, review the 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 PATCH release:

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 MINOR release:

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