Currently Lerna is bumping versions of all the components, even if some components have had no code changes.
This is undesirable because of 1) the way semver works and 2) because these are design components.
Minor version bumps in PFE are going to include design changes, and as hard as we try to make designs work with everything, invariably there are going to be edge cases we're not thinking about and solving for. So downstream projects should opt into minor versions and test things before pushing to prod, to avoid inadvertent updates that might change the look of something unintentionally.
The general recommendation then, is that they should probably lock the major & minor versions and opt into patch updates only, which fix bugs but don't drastically change any designs.
"@patternfly/pfe-card": "1.1.x",
"@patternfly/pfe-cta": "1.1.x",
To continue this hypothetical scenario, let's say in the PFE project, the pfe-card gets several updates. So its legitimately at 1.4, whereas the pfe-cta is not really changing, but it keeps getting minor version bumps too, so it's now at 1.4. Since the downstream project is only interested in the card changes, and they don't have time to test the CTA, they update their dependencies to:
"@patternfly/pfe-card": "1.4.x",
"@patternfly/pfe-cta": "1.1.x",
Then the day comes where a patch release is created for the pfe-cta. The downstream project wants that fix. But instead of it being a 1.1.1 patch, it is now a 1.4.1 patch, which they will never receive unless they manually update the package.json again, which differs from their expectations.
Implementation suggestions:
- Use the "Independent mode" setting in Lerna
Currently Lerna is bumping versions of all the components, even if some components have had no code changes.
This is undesirable because of 1) the way semver works and 2) because these are design components.
Minor version bumps in PFE are going to include design changes, and as hard as we try to make designs work with everything, invariably there are going to be edge cases we're not thinking about and solving for. So downstream projects should opt into minor versions and test things before pushing to prod, to avoid inadvertent updates that might change the look of something unintentionally.
The general recommendation then, is that they should probably lock the major & minor versions and opt into patch updates only, which fix bugs but don't drastically change any designs.
To continue this hypothetical scenario, let's say in the PFE project, the pfe-card gets several updates. So its legitimately at 1.4, whereas the pfe-cta is not really changing, but it keeps getting minor version bumps too, so it's now at 1.4. Since the downstream project is only interested in the card changes, and they don't have time to test the CTA, they update their dependencies to:
Then the day comes where a patch release is created for the pfe-cta. The downstream project wants that fix. But instead of it being a 1.1.1 patch, it is now a 1.4.1 patch, which they will never receive unless they manually update the package.json again, which differs from their expectations.
Implementation suggestions: