Release Strategy
Camp uses semantic versioning for releases with the following approach to release strategy.
Pre-releases
Pre-releases (e.g., 0.0.1, 0.1.0) are used for components that are new without a proven track record of stability. This state of stability is difficult to quantify and differs based on component complexity. For example, the more complex Rich Text Editor component stayed pre-1.0 for months while it was being introduced into the platform. Other components may hit the first major release more quickly. Being a pre-release doesn’t mean that a component is not usable. Any release from Camp is intended for usage unless otherwise noted. But, pre-releases will likely be in a greater state of flux, and so we will respond very quickly to platform needs for them. If you are using a pre-release component and uncover a bug or feature request, let us know in #help-design-systems , and we will be quick to prioritize it.
1.0 Release
The first major release is typically reserved for components that have a proven track record of stability. This means that the component has been introduced into the platform and been tested in a variety of scenarios. Markers for this on our end is that we know of multiple situations where they are used and help requests have leveled out for features/bugs. Every so often, we will go against this standard because a breaking change will have to be released while the component is still gaining traction in the platform. This is rare, and we will note it in the docs page for that component if this happens.
Other releases
Following 1.0, we follow traditional semantic versioning. This means that we will use the following format for our version numbers:
- Major releases (e.g., 2.0.0, 3.0.0) are reserved for breaking changes that are not backward-compatible.
- Minor releases (e.g., 1.1.0, 1.2.0) are reserved for new features and fixes that are backward-compatible.
- Patch releases (e.g., 1.0.1, 1.0.2) are reserved for small bug fixes, chores, or improvements that do not introduce new features or breaking changes.
Tooling
In terms of the tooling we use in Camp Next Gen, we use Nx and more specifically nx release
. In that, we use semantic versioning and Conventional Commits for automating releases based on commit messages via nx release.