You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We already added some new features to the style spec and there are more to come. It is the intention to keep the style spec backwards compatible. This means that we need to be very careful when adding new features to get the style spec correct from the start as it is hard to change later. This again places a big burden on implementing new features for example in #1191.
Design Alternatives
new features are merged to main but marked as experimental without any guarantees.
new features are developed in a branch for potentially a long time until we have enough input and experience with it.
new features are merged to main, but then we allow for a long dev cycle to a new release to figure out the best style spec.
live with technical debt in the style spec
live with breaking backward compatibility when we fix the style spec
Design
As the title suggests I'm for the first option. For this we should imho have the following:
a way to mark parts of the style spec as experimental
a general documentation what we mean by experimental features
the api documentation should mark experimental features with a link to the general explanation
an option to enable experimental features which is off by default
I do thinks we could just add some documentation and then go forward with #1191 without blocking on all the above points though.
The text was updated successfully, but these errors were encountered:
I also favor the first option.
I also think there's a need to define a process of making something from experimental to officially supported so that features do not remain experimental forever or for a long time.
I think this is issue is a good start for this needed discussion, thanks!
Motivation
We already added some new features to the style spec and there are more to come. It is the intention to keep the style spec backwards compatible. This means that we need to be very careful when adding new features to get the style spec correct from the start as it is hard to change later. This again places a big burden on implementing new features for example in #1191.
Design Alternatives
Design
As the title suggests I'm for the first option. For this we should imho have the following:
I do thinks we could just add some documentation and then go forward with #1191 without blocking on all the above points though.
The text was updated successfully, but these errors were encountered: