Skip to content

Breaking change flow #623

Description

@rosslo

Why:
As we are doing design sync stuff, we will have to change the style or behavior which might cause a breaking change.

How:
For any potential breaking change, before we merge the change into v4, we should

  • Ensure the change being backward compatible.
  • Use console.warning to warn the developer about the legacy props.
  • Mark deprecated codes with @deprecated tag so the other developers can easily be aware of it from IDE.
  • Add the announcement about the legacy stuff on the storybook and slack (after merging into v4).
  • Create an issue for removing legacy features.

So the breaking changes won't break the production or block the other features and we won't be forced to migrate it on the projects asap.

After we migrate the breaking change on projects and merge the branch into staging, we can start to remove the legacy codes on glints-aries.

Example:
The two examples below both blocked the other features release before because we didn't make the change be backward compatible.

  • Color:

    • Slack: https://glints.slack.com/archives/CS09D0LJX/p1612494365026900
    • PR: Remove Deprecated Colors #583
    • Breaking change: Some color variables got renamed or removed.
    • How should we do:
      1. Add new colors and still keep the deprecated colors in src/Utils/Colors.ts.
      2. Remove deprecated colors from the storybook.
      3. Merge branch into v4 and announce the coming breaking changes on slack.
      4. Upgrade glints-aries and replace the legacy color variables with new ones on projects.
      5. After we merge the breaking change migration into staging, we can remove the legacy colors on glints-aries.
  • TextField:

Activity

  1. rosslo commented on Mar 15, 2021

    @rosslo
    ContributorAuthor

    Question:

    • Should we build a tool/ script to find the use of an Aries component with a given property?

    Concern:

    • Aries component wrapped by styled is not trackable by jscodeshift.
  2. westwood846 commented on Mar 26, 2021

    @westwood846
    Contributor
    • Should we build a tool/ script to find the use of an Aries component with a given property?
      I think I could adapt my tool for counting the usages of the code units for this quite easily.
  3. westwood846 commented on Mar 26, 2021

    @westwood846
    Contributor

    I think @deprecated is the way to go. We just have to make it sufficiently visible that a code unit it going to be removed. That way we prevent new usages. And then we can replace the old usages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DocumentationIncludes Storybook and Github README

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions