Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADR: Parallel drafts track & plan for deprecated components #1722

Merged
merged 15 commits into from
Jun 20, 2022
Merged
46 changes: 46 additions & 0 deletions contributor-docs/adrs/adr-005.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# ADR 5: Parallel experimental track & plan for deprecated components

## Status

Proposed

## Context

As we work on maturity of our components, we will sometimes need to build components in a parallel track/bundle without breaking existing components. Eventually, the new components would replace the old ones in the main bundle.

## Here are the 3 proposed stages:

### Stage 1

Start new component outside the main bundle. Folks who want to try it, need to explicitly import it from the `drafts` bundle.
siddharthkp marked this conversation as resolved.
Show resolved Hide resolved

`import { ActionMenu } from '@primer/react/drafts'`

The contract with consumers is - you are opting into a rewrite of the old component that might not cover all the cases of the old component yet. If you are using both the old and new version of the component in different pages, you are paying some additional bundlesize cost.

Note: If it is a 1:1 replacement, it's useful to keep the component name the same for consumers. Internally, we would want to call the filename `ActionMenu2.tsx` and call it `ActionMenu v2` in the docs.

### Stage 2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Non-blocking] We may want to consider a @primer/react/next bundle where we put replacement components when we're "confident" in the API. This will allow consumers to migrate to the new components on their own schedule ahead of the breaking release described in Stage 2

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that separate from @primer/react/next? 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand the question 😅


After we have the confidence that this component is better than the old version of it, we swap the components and move the old component out of the main bundle.
siddharthkp marked this conversation as resolved.
Show resolved Hide resolved

This is a breaking change! We are now officially recommended that consumers start using the new component, but if they'd like to push that effort to the future, we give them an easy way out -

`import { ActionMenu } from '@primer/react/deprecated'`

The deprecated component does not accept new features requests.

Reason: Because we have a single bundle for all components, you can not pick the components you want to upgrade. This can result in additional unrelated work.

### Stage 3

After 3 months of living in the `deprecated` bundle, a component is retired/deleted from the codebase. This is also a breaking change.

At this point, consumers are expected to plan migration work.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some additional notes for this section:

  • The deprecated component should be marked as deprecated on the documentation page with information about how to migrate to the recommended component
  • The link to the deprecated component should be moved to the Deprecated section of the navigation
  • The title of the page should change to ComponentName (legacy) if we replaced it with a component of the same name

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a long list for "deprecating a component" 😅 Should we add that to the contribution docs instead of ADR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add that to the contribution docs instead of ADR?

Yup, makes sense to me 👍


## Suggested changes:

We should detangle "drafts" from component lifecycle.
siddharthkp marked this conversation as resolved.
Show resolved Hide resolved

"Drafts components" should not be collocated with "main bundle" components in the documentation or status page. They should have their own section because they are not recommended as an alternative yet.