RFC: Accessing old storybook documentation

[gfellerph]

The Design System will eventually evolve and we'll publish more and more versions of the styles and component packages. Not every project will always be able to keep up to date and may need to access the documentation of the exact version they are using.

In this discussion, I'd like to collect ideas on how we can publish our storybook in a way that it's possible to load older versions. There is a list of information we have available and can use to achieve this and also a list of challenges we face with our specific approach.

Available information:

• The storybook version is independent of the styles and component versions, but is bumped every time one or the other changes
• There are git tags for all packages we publish to npm, but not for the storybook package (tagging is handled by the changeset action but it only works for packages that are being published, we could manually tag storybook releases or publish a placeholder package to npm to use the existing workflow)
• Chromatic has a versioning feature
• It's possible to publish older versions in subfolders to netlify, e.g. https://design-system.post.ch/v5.0/index.html

Challenges:

• All the packages are individually versioned so there is no longer a "Design System Version". Components might be at v2 while the styles are at v7 and the docs are still at v5. Every docs version is tied to a specific styles and components version so it would be possible to create a table and let the user choose the specific docs version that describes the styles version he needs. Granularity (should the list contain each patch, minor or just major change) and level of abstraction (should it be a table or just a list of links for every package with behind the scenes mapping) need to be discussed
• When should version extraction happen (build time on PR branch, release PR, client side at runtime, ...)

[gfellerph]

Relevant #1239

[gfellerph]

Two approaches are currently in discussion with tendencies to the second option:

1. Netlify does not delete the most recent branch release as long as the branch exists. This means we could publish release/v5 versions as branch releases and keep them as long as we keep the release branch open
   ++ Current setup is sufficient for that and besides creating the release branch, no further setup is required for major releases
   -- URLs look ugly (like https://preview-1418--swisspost-web-frontend.netlify.app/) and change with every new patch of old versions -> we then have to update versions.json on the main branch

2. We could push v5 releases to a new site in netlify and proxy to this site from our main site
   ++ Nice URLs that don't change with every patch like https://design-system.post.ch/v5
   -- We have to set up a new site in netlify for every major release and also add the new site id and PW to github secrets (but I think there is a way to write workflows flexible enough that they'll work without extra setup)

[gfellerph]

Decided to go with 2. as the main disadvantage can be automated.