Alaska Airlines
Node version support, MAJOR releases and the AuroKit concept #565
Replies: 2 comments 1 reply
-
|
Another thing we could consider is, if we do decide that moving Node versions IS a BREAKING CHANGE, the opportunity here is to be fairly predictable with our updates as Node's schedule is well planned. 
Combined with the BETA release process, we can aggregate our BREAKING CHANGEs and plan work accordingly to prepare a BREAKING CHANGE release around the October LTS release of Node. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea that we would plan to have at least one breaking change release per year so as to keep up to date with Node versions, but I would be cautious about leaning back on node version releases ever being our only time we make breaking changes. We've talked before about wanting to "bundle" some of our beta releases into a more quarterly cadence. I think if we take the course of aggregating all our breaking changes into one release a year, that may be too few and too far between. It also will lead to a large lumpsum of testing effort and hot fixing across all our components all at once. Obviously there can be some wiggle room here. For example, if we have other changes which would constitute a major release we hold them for a month or so to release with the yearly Node updates, but I don't feel it's feasible or ideal to hold breaking changes from February in a Beta branch until October when we can release them with Node updates. I think it's up for discussion with product where that line is on what would be holding something in beta "too long" be. I do like the idea of removing deprecated code/features in our yearly Node releases. |
Beta Was this translation helpful? Give feedback.
-
|
There are threads of thought with this Discussion shared with this https://github.com/orgs/AlaskaAirlines/discussions/564 Discussion. |
Beta Was this translation helpful? Give feedback.
-
Updating the required Node version in the
package.json, for example, from supportingv18andv20tov20andv22can be considered a breaking change if the consumers of the repository rely on the specified Node version for their local development and build processes. Here’s the reasoning:Problem
When updating the Node version required by a repository from
v18andv20tov20andv22, is this considered a breaking change according to Semantic Versioning (SemVer)?Recommendation
It is recommended to treat this update as a breaking change. While the web component itself is not dependent on Node, the
package.jsonspecifies the Node version needed for local development and the build pipeline. Updating the Node version requirement can affect developers who use the repository, as they may need to upgrade their local Node environment to meet the new requirements.Expected Outcomes
Conclusion
Since changing the required Node version from
v18andv20tov20andv22can break the existing local development setup for developers using Nodev18, it should be treated as a breaking change. Incrementing the major version number will signal to developers that they need to review and possibly update their local Node environment to continue working with the repository.Additional context: AuroKit
When AuroKit, a bundled package of individual npm packages, is updated with a BREAKING CHANGE, even though the individual packages are only patch incremented, how should this be managed and communicated?
Considerations
Ensure that the breaking change in AuroKit is not due to the individual packages but rather due to changes in how these packages are bundled or interact together. Review if any new dependencies or major changes in the build or configuration process have been introduced.
Even if individual packages only have patch updates, AuroKit's version should reflect a breaking change if the integration or usage of these packages within AuroKit has breaking changes. This ensures that consumers of AuroKit are aware that they need to review their integration with the updated AuroKit version.
Clearly document the nature of the breaking change in AuroKit. Explain that while individual packages have minor updates, the way they are integrated or utilized within AuroKit has changed significantly. Provide a migration guide or detailed release notes to help consumers understand and adapt to the breaking changes.
Conduct thorough testing to ensure that the integration of the individual packages within AuroKit works as expected and that the breaking changes are well-defined. Validate that the breaking changes do not introduce unforeseen issues in the consumer’s environment.
Communicate the breaking change effectively through release notes, changelogs, and announcements. Ensure consumers are aware of the update and the steps they may need to take. Highlight the benefits or improvements brought by the breaking change to justify the major version increment.
Consider providing backward compatibility layers or deprecation warnings for a few versions if feasible. This can help consumers transition smoothly to the new version without immediate disruptions.
Beta Was this translation helpful? Give feedback.
All reactions