Check dependencies on bullet_train-fields
jagthedrummer opened this issue · comments
I noticed that some of the other BT gems show up one version behind in the lock file for the fields gem.
Currently Up-to-Date Gems
bullet_train-fields (the gem itself)
bullet_train-api
bullet_train-super_scaffolding
bullet_train
Outdated Gems
bullet_train-has_uuid
bullet_train-roles
bullet_train-scope_validator
bullet_train-super_load_and_authorize_resource
bullet_train-themes
TL;DR
The outdated gems listed above are dependencies of bullet_train which was explicitly added later on in #675.
A Brief History
In bullet_train-fields, we added the peer gems bullet_train-api and bullet_train-super_scaffolding in #667 so these have stayed up to date.
You can see that the up-to-date gems mentioned above (besides bullet_train) are listed in #671, but the out of date gems are overlooked in this PR, so this is where they fell behind. Here is a screenshot showing that it's the first version bump after making the changes in #667, so it makes sense that this is where it happened:
bullet_train itself is currently up to date though because we explicitly added it shortly thereafter in #675, and you can see the version jump it makes from 1.6.13 to 1.6.15 in this PR.
It looks like things were skipped once again in #682 (the first edit to Gemfile.lock after #675), and then the gems have been on track since.
Because the outdated gems are still being bumped automatically, I think we'll just have to make an explicit version update for those gems to account for the skip that happened, and then we'll be on track.
Reopening this because it's still an issue.
I just bumped the gems to 1.6.29 but 1.6.28 is still showing up for some of them.
bullet_train-core/bullet_train-fields/Gemfile.lock
Lines 158 to 164 in 89c4cd1
I think if we update every Gemfile on every gem in the core lib to point to the local version of any dependency that's declared in the .gemspec then things should keep up to date automatically.