This summary of releases is to mark the beginning of the IDS Branching Strategy, introduction of themeability and the dark mode for the documentation site.
Overview
This is release notes for every change from v14.0.0 until v14.22.3.
We've focused on delivering components with themeability in mind, with using the already existing Design Tokens as CSS Variables. We have also prepared the IDS Branching Strategy, beginning with Relax!
For a full overview of changes, see the changelogs, or the board.
What’s new
- Design:
- IDS Branching Strategy in place!
- Develop:
- Most (soon all!) of our core components have now their own respective Design Tokens and CSS Variables
- IDS Branching Strategy in place!
- Documentation site:
- We did some layout adjustments for the documentation site, for a more clean look
- Updated the icon page
- Added support for Dark Mode!
- Added support for User Settings!
- React Components:
- All of our React components are now using CSS Modules
- Added Text component
- Added Heading component
- Core Components:
- Adjusted the FAQ Component
- Added small Icon Button variant
- Added small Button variant
- Added support for inverse buttons
- Improved the spacing between breadcrumbs and heading in the Header Component
- Added component specific CSS Variables to many components, making it easier to theme, adjust and customize the components
- Internal
- All of our packages now have a centralized JSON file that is an inventory of our components
- Added more features for our documentation helpers
- The component status page has been revamped and is now generated per view
- Adjusted the changelog generation to include commit body
- We are now using Conventional Commits instead of Angular presets for our commits
- Converted many components to use MDX instead of Markdown. This allows us to use React components in our documentation
What’s not changing
- No breaking changes! :)
Release FAQs
What are the benefits of the current state of If Design System for me as a designer?
- Better control over component customization
- More options when viewing our examples
What are the benefits of If Design System for me as a developer?
- Better control over component customization
- More options when viewing our examples
Do I need to update right away? If not, when will we need to update?
- There are no critical changes for updates, but to get the latest CSS Variable stuff, update! We always recommend to update on a regular basis.
Will I need to redesign something?
- No
How big is the expected effort to migrate code to the latest version?
- None
Branching FAQs
What is the IDS Branching Strategy?
To alleviate the maintenance for the IDS Team, and to make the consumers day to day life easier, we have opted in for a branching strategy for our Design System. This means that the IDS Team will now focus on creating and maintaining the core components of the design system. Many components have been created with special focus on the needs on specific teams. It is now up to the teams themselves to maintain those components.
In short terms, each team that has specific components in the IDS will own and maintain their components in a repository and scope managed by the IDS team. for relax that would be ids-relax-core-repo and @ids-relax-core-scope. For Open Pages, it will be ids-open-pages/@ids-open-pages, postfixed if necessary with -core or -react, depending on framework.
This will allow for better sharing and discoverability of the components themselves, between designers, developers, teams and content managers. If a component in a branch is found to be of use for several teams, we will put that component in the IDS core repository and scope.
With the introduction of the component specific CSS Variables, it will be easier to create your own variants, and to customize components to fit your needs.
With the IDS Branching Strategy, the teams are no longer directly dependent on the release cycle of the IDS Core, making the development life easier.
All of the component and design documentation for the respective branches/teams, is placed on our documentation site.
How to inherit/depend on IDS Core when we are currently not being able to keep up with new versions?
Only the specialized components are to be moved into their respective teams repo and scope, so the dependency would be tied directly to IDS core in form of either CSS inheritance, Design Token usage (preprocessor variables or CSS variables) or direct overrides. The specialized components can fix their IDS core version as a dependency, if required.
How to keep up/handle with breaking changes in IDS Core?
See former point.
Who is in control when breaking changes effecting the custom components should be done? Can we veto it?
Breaking changes from IDS Core cannot be vetoed on a regular basis, but the IDS Team can be notified of any concerns during our PO checkins and demos. For your specialized components, you are free to follow your own release cycle.
Could IDS Core be backwards compatible?
Backwards compatibility is never achieved while using a Semver setup, as in major versions. minor and patch-versions are backwards compatible. We still have rules in place for backward compatible bug fixes for a set of versions.
How to synchronize the dependency our custom component will have to the Core?
That is up to you. You can either update deps on the fly, or fix a version to the IDS Core, as long as it does not hinder updates of the VID.
The normal state is that we are one or two versions behind, how will that effect the new setup?
We suggest that you get up to speed of your deps to the latest version before starting the branching strategy. YMMV, so we are always open to discuss your concerns!