-
Notifications
You must be signed in to change notification settings - Fork 21
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
fix: update pagination statusLabel type to ContentNode #1099
Conversation
Preview branch generated at https://fix-958.d1gko6en628vir.amplifyapp.com |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This cannot land without a deprecation period according to our contributing guidelines:
Before a breaking change can be released, the breaking change should be documented with the component, property, or style being changed getting flagged as Deprecated. This could mean warning the consumer that a component or property is now deprecated, or including a deprecated comment next to a css class name. This deprecation must exist for at least two months. If a change is additive (e.g. making a new property required), the new property must be optional until the deprecation period has passed.
I'm not 100% sure how we address this given it's a type change but it cannot land with our current guidelines.
I am also unsure how to handle it. Maybe we could adjust the name of the prop and recommend future uses utilize the new name? I know that is likely not ideal especially if it is used in other parts of the repository. |
After further consideration, I'm going err on the side of this not being a breaking change. Someone who is passing in |
Preview branch generated at https://fix-958.d1gko6en628vir.amplifyapp.com |
BREAKING CHANGE: update pagination statusLabel type to ContentNode
This closes #958
We need to discuss how to handle this change because as mentioned in the issue it is a breaking change.