Skip to content

Latest commit

 

History

History
53 lines (38 loc) · 2.09 KB

DEVELOPING.md

File metadata and controls

53 lines (38 loc) · 2.09 KB

Developing the UI Extensions SDK

API documentation and changelog

We use semantic versioning.

A commit that changes the public API of the SDK must come with a changelog entry and an update to the API documentation. The entry in the changelog should follow the “Keep a Changelog” format.

For additions the API documentation must end with “In upcoming release”. If a new version, say v1.2.3, is released this must be changed to “Since v1.2.3” in the release commit.

For API changes the documentation must end with “Changed in upcoming release”. If a new version, say v1.2.3, is released this must be changed to “Changed in v1.2.3” in the release commit.

Styles and Styleguide

We use Stylus to build the stylessheets from lib/styles. The task make styles will create dist/cf-widget-api.css. We also use KSS to turn comments in the style files into a styleguide. You can build the styleguide with make styleguide which will create HTML files in dist/styleguide.

Updating GH Pages distribution

We use Github Pages to distribute the styleguide from the ./docs folder.

If you make any changes to the stylesheets run make build-pages to update the ./docs directory and add it to your commit.

For backwards compatibility we also distribute the code and styles for v2.1.0 from Github Pages. These are not updated automatically anymore since we use unpkg.com.

Releasing a new version of the SDK

  1. Add new release to changelog by renaming “Upcoming” to “v1.2.3”.
  2. Update API documentation for added methods to include the version they were added in (e.g. “Since v1.2.3”, “Changed in v1.2.3”)
  3. Update the version in package.json.
  4. Update the [files][npm-files] property in package.json if necessary.
  5. Commit to master.
  6. Tag commit as vX.Y.Z and push tag to GitHub
  7. Publish new version of package on npm