For our foreman-js meta-packages (like @theforeman/vendor), I was told to update them all together when updating one, so in this PR, I updated @theforeman/test to 6.0.0, but needed to update the other @theforeman/* packages to 6.0.0 as well.
Seeing something like katello-nightly-rpm-pipeline 756 failed makes me wonder if there is a way these can be updated independently. @theforeman/builder updated to 6.0.0, so Katello’s version was no longer available in packaging. But there were no breaking changes in @theforeman/builder, it just was updated along with the other packages. Ths means that pinning to certain version ranges doesn’t behave as expected.
What is the reason for us updating all the packages together right now? More specifically, what I’m wondering is:
- Can we publish
@theforeman packages independently to npm so they maintain their own semantic versioning?
- Can we define the relationships between
@theforeman packages better so they don’t have to be updated together when one package was updated?
cc @ui_ux
I don’t see any reason why the packages can’t be versioned separately. We were probably doing it just because they’re all hosted via lerna in the same Github repo. But each package does have its own package.json which can be versioned separately, unless there’s some technical limitation I don’t know about.
Yeah, I also think it’s more for a convenience reason, altough we should then (as John is saying) define more rigid dependencies and set bit more formal processes (write them up in the foreman-js repo would be fine I guess) what needs to be done on each of the version bumps.
Now the processes are quite easy, even though not very convenient. You bump all of them together and then bump them in all plugins xD It would be great to have something better than that, but last discussion on this topic didn’t bring any good answers IIRC.
would be good to get more opinions here - right now we’re again stuck with the major version being bumped to 7.0 just because we updated the storybook version which had incompatible changes, which doesn’t even effect build time but we can’t update minimal requirements in core or plugins without either packaging 7.x or breaking packaging.
From my side I would be +1 for unlinking the versions, unless there is a good reason that a change in one package depends on a change in another package, in which case we would want to bump the first package anyways.
1 Like
I’m not as familiar with lerna, but glancing at their docs and the foreman-js code, it looks like we are using fixed mode instead of independent mode.
I think our use case calls for independent mode, we could avoid packaging updates when just a development dependency is updated, not to mention avoiding pipeline breakages.
Is there anything preventing us to switching to lerna’s independent mode? What would that take?
3 Likes
