Branches

What is IDS Branches..

Table of Contents

Background

Get started

FAQ

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 beids-relax-core-repo and @ids-relax-core-scope. For Open Pages, it will beids-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 verions?

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. minorand 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!

Resources