Release Guidelines

Experimental features

Only stable, well tested components and packages may be present in the main or development branches. Any publishable code in the main or development branches must have been tested in both The App and FT.com. This is so we do not release unproven components with a stable version number.

To develop your component create a new feature branch including your module name, for example if you are building a new tabs component you would create a branch named feature-x-tabs. Your component will stay in this branch until it is ready to be merged into the next major or minor release so you are encouraged to merge from or rebase onto the latest development or main branch regularly. You are welcome to raise pull requests against your feature branch if you need to.

When your new module is considered stable raise a pull request against the current development branch, you can then release a new version of x-dash following the Releasing/Versioning guide below.

Releasing/Versioning

All of our projects are versioned using Semantic Versioning, you should familiarise yourself with this. The following guide will outline how to tag and release a new version of all projects, it assumes that all the code you wish to release is now on the main branch.

1. Review the commits since the last release. You can find the last release in the git log, or by using the compare feature on GitHub. Make sure you've pulled all of the latest changes.

2. Decide on a version. Work out whether this release is major, minor, or patch level. Major releases are generally planned out; if a breaking change has snuck into main without prior-planning it may be worth removing it or attempting to make it backwards-compatible.

3. Add a release. Create a release using the GitHub UI (note there should be a "v" preceeding the version number). This will automatically kick off a new build and publish each package.