Updating the Clarity release and support strategy
The Clarity Design System has been open sourced for over a year, and we’ve settled on a path for getting us to an official 1.0 release. VMware has over 100 various products using Clarity, with many more external users. While we consider Clarity to be a stable project and have been careful to limit breaking changes between 0.x releases, we know how important it is to have a clear strategy for what to expect from your design system.
To that end, we’ve outlined our policies on how and when we plan to release new versions of Clarity, so you can plan accordingly for your projects.
Semantic versioning and time based release cycle
Clarity has adopted semantic versioning (semver), except we aren’t version 1.0 yet and have been using minor releases for breaking changes. This is a common practice, but we feel it can also cause some confusion. Therefore, we’ve setup a plan to release two more minor releases (0.12 and 0.13), and then when we release version 1.0 we’ll follow proper semver in our releases.
In other words, after 1.0, you can expect breaking changes to only occur when 2.0 is released. Any versions of 1.x.x will remain backwards compatible and any new features that can be shipped without a breaking change should make it into the 1.x releases.
Expect new major releases every 6 months, properly following semantic versioning rules starting with version 1.0.
We also have been releasing versions on an irregular schedule, primarily when we have a breaking change we need to introduce. Many features (like the new datepicker) were introduced without a breaking change, but other features (like the upcoming forms refactoring) would wait for the next release with breaking changes. This can cause pressure to schedule features and releases, which can cause friction and takes time to manage.
To address this, we’ve decided to also move to a 6 month release cycle for major releases that may introduce breaking changes. We’ll focus on shipping features when they are ready, and only ones with breaking changes need to be scheduled for the next major release. That means only twice a year should you have to worry about breaking changes during an update, if you stay on the latest version of Clarity.
Introducing Long Term Support for Clarity
In addition to time based releases, the biggest announcement with Clarity 1.0 is that every major release will come with a long term support (LTS) policy that is a guidance for how we plan to support each major release of Clarity. Here is how we’ve defined LTS:
Clarity defines Long Term Support (LTS) as providing support for severe or security bugs for a release, for 12 months after the release of the next major version.
Starting with version 1.0, we’ll support each major release for 12 months after the release of the next major version. In practice, this means using a version of Clarity will actually get you 18 months of support, 6 months of active development before the next major release, and then 12 months of support. To visualize this, we’ve created the following example of how versions are developed, released, and supported.
At VMware, some of our products have long term release schedules and we expect this change to ease concerns about adopting Clarity. It will be most helpful in situations where releases cannot deal with breaking changes but still want to be sure of security and bug fixes.
We’re still rolling out pre-1.0 releases, and 0.12 and 0.13 are scheduled for shorter cycles to help us move to version 1.0. Our plan is to release Clarity 1.0 later in 2018, and these shorter minor releases will help us introduce the necessary changes we need before an LTS release.
Linking releases to Angular’s schedule
Angular has outlined their plans for their release cycles for some time now, which includes a new major release approximately every 6 months, with every other version being a long term support (LTS) release, which would have an additional 12 months of bug fixes and security patches.
Last week at ng-conf 2018, Brad Green, project manager for Angular, announced that every major release will enjoy the same long term support starting with Angular 5. So Angular’s new release schedule looks like this.
We had this change in mind when deciding on our LTS strategy, because you should use Angular for the best experience with Clarity. This alignment between our releases and support schedules means Angular and Clarity will work together without worrying about gaps in support.
The road to Clarity 1.0
There are a few things we need to do with Clarity to get to version 1.0. The list includes a form design refactoring with new Angular components, an updated grid implementation, several new components like an advanced select box, normalizing some of the CSS and APIs, and deprecating and removing some features.
We use GitHub milestones to outline what goes into a given release. We’ve already created tickets with known deprecations and breaking changes expected in upcoming releases, so if you’d like to see our plans this is the best place to look.
We’re also trying to minimize breaking changes as much as possible, and are planning a special compatibility layer for some breaking changes expected in 1.0. This is primarily to help with the migration from 0.12 to 1.0. More details will be released when we have these details finalized, but it is our intention to allow you to opt into this compatibility layer to ease the update to 1.0.
Building and maintaining multiple versions of Clarity is something we’ve carefully considered and feel that the benefits of this approach will be meaningful for our users. Please let us know if you have any questions about the path to 1.0 or our support policy!
To learn more about Clarity or engage with us, follow us on Twitter, see the our GitHub repository, and visit our site at http://clarity.design.
