-
Notifications
You must be signed in to change notification settings - Fork 88
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
docs(adr): Increase ReactUSWDS version when updating USWDS version #1045
Conversation
## Considered Options | ||
|
||
- Bump the ReactUSWDS major version when updating USWDS minor & major versions | ||
- Bump the ReactUSWDS version with the same release type as USWDS |
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.
I vote for Bump the ReactUSWDS version with the same release type as USWDS
. We probably should also acknowledge this means we don't anticipate maintaining multiple active versions of the library. For example, we wouldn't back port a new component or bug fix to a previous USWDS version.
- Bump the ReactUSWDS major version when updating USWDS minor & major versions | ||
- Bump the ReactUSWDS version with the same release type as USWDS |
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.
I'm comfortable with option 1 or option 2.
We know that uswds
does release presentational changes that are sometimes not mentioned in the release notes, which we could consider breaking changes.
Reading the uswds
release process makes me actually lean towards option 2. If our library is simply a react-wrapper for uswds
, is there really any value to us being more strict than usdws
? Option 1 would mean that projects depending on both libraries would have minor version updates for uswds
and a major version updates for react-uswds
for the same changes. Specifying the package.json dependencies on a consumer project would be weird in that context. For example, if you use ^2.10.0
for uswds
, you wouldn't have a good equivalent for react-uswds
without also opening yourself up to other breaking changes. It kind of sounds like we're wanting consumers to manually manage the versions of USWDS and ReactUSWDS, so maybe that concern isn't as big of a deal as I'm making it sound like.
Related note (to option 2):
I would've thought based on
the following should trigger a major version increment:
- Changing the way in which elements with .usa- class names are structured in HTML
that the 2.10.1 change (a patch version change!)
Now we're using a
p
instead of anh3
for usa-footer__logo-heading
would have constituted a major version change.
But ultimately for me its coming back to "What does being more strict than the library we're wrapping ultimately buy us?". If consumers are expected to manually manage these versions, the stability of this library's versions isn't as big of a concern.
Based on today's meeting I think we have consensus around option 2 🎉. Thank you @suzubara for gathering these options. Next steps for implementing this ADR could be:
|
ef7720c
to
1129029
Compare
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.
Our first ADR 😭 😍 . Look at us deciding things.
Suggestion: also add this line to the first page of our README so its front and center.
|
…wds into sr-uswds-version-adr
…1045) * Add draft of ADR * Update ADR with chosen decision * Added note about order of implementation
Summary
Adds an ADR to help us decide ReactUSWDS versioning as it relates to USWDS versions.
I also copied the ADR template @brandonlenz introduced in #1026
Related Issues or PRs
Resolves #343