-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Introduce Solidus update process #4087
Introduce Solidus update process #4087
Conversation
core/spec/lib/generators/solidus/update/update_generator_spec.rb
Outdated
Show resolved
Hide resolved
core/spec/lib/generators/solidus/update/update_generator_spec.rb
Outdated
Show resolved
Hide resolved
core/spec/lib/generators/solidus/update/update_generator_spec.rb
Outdated
Show resolved
Hide resolved
core/spec/lib/generators/solidus/update/update_generator_spec.rb
Outdated
Show resolved
Hide resolved
core/spec/lib/generators/solidus/update/update_generator_spec.rb
Outdated
Show resolved
Hide resolved
bb57f23
to
4257935
Compare
d9873f2
to
b987865
Compare
8fe9540
to
f52217c
Compare
f52217c
to
144ab8d
Compare
6e77f4b
to
3b39a8a
Compare
3b39a8a
to
7dff340
Compare
@kennyadsl in the last commit, I added the warning prompted to the user that we discussed offline yesterday. We still need to keep track of the previous solidus minor version, so once it's merged, we need to update https://github.com/solidusio/solidus/wiki/How-to-release-Solidus |
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.
Love it! Left some questions, though.
One extra step may be having a generic load_default function for users that has all the solidus components in place. Maybe we can automatically skip defaults for subcomponents (constants, like Spree::Backend
) that are just not defined. Of course, if you think it's a good idea we can iterate on another PR. Thoughts?
Thanks!
update.mp4This is a short demo showcasing how the process works |
core/lib/spree/core/preference_changes_between_solidus_versions.rb
Outdated
Show resolved
Hide resolved
43e316a
to
16d88ef
Compare
Following the work done in solidusio#4064, this commits introduces a Rails generator that creates a new initializer called, by default, `new_solidus_defaults.rb`. This initializer works in a very similar way that [`new_framework_defaults.rb` does in Rails](https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#configure-framework-defaults). It allows users to preview the defaults that have changed on a new Solidus version, as they are printed one by one on a commented line. Users can then keep enabling them while updating their application code. We're adding the `load_defaults` call with the old version value to the generated initializer. Users can remove the file altogether when they're done with the process. At that point, we require them to add `load_defaults` with the new version to the main initializer file (`spree.rb`). Even if there's no actual need for that, as `loaded_defaults` on the configuration class defaults to the current Solidus version, we want to enforce that so that users are on the safe side for the next version upgrade. If they don't add it, we emit a warning. For now, we're leaving this as a generator, but we could reference it from a rake task, although probably there's no need. Be aware that users need to provide the version from which they are updating. It's an option that offers more flexibility, as users can update from versions different from the latest one. It also plays well with our system's flexibility, for instance, to change defaults between a pre-release and a release. However, we can add some code to default to the latest minor version, but we should keep that information in our code, and that's a small burden for our update process.
16d88ef
to
c9a4e61
Compare
The method is leftover after extracting solidus_frontend from the mono-repo. It was introduced in solidusio/solidus#4087 to be used in the update generator, but it's the business of solidus_core.
Following the work done in #4064, this commits introduces a Rails
generator that creates a new initializer called, by default,
new_solidus_defaults.rb
.This initializer works in a very similar way that
new_framework_defaults.rb
does inRails.
It allows users to preview the defaults that have changed on a new
Solidus version, as they are printed one by one on a commented line.
Users can then keep enabling them while updating their application code.
We're adding the
load_defaults
call with the old version value to thegenerated initializer. Users can remove the file altogether when they're
done with the process. At that point, we require them to add
load_defaults
with the new version to the main initializer file(
spree.rb
). Even if there's no actual need for that, asloaded_defaults
on the configuration class defaults to the currentSolidus version, we want to enforce that so that users are on the safe
side for the next version upgrade. If they don't add it, we emit a
warning.
For now, we're leaving this as a generator, but we could reference it
from a rake task, although probably there's no need.
Be aware that users need to provide the version from which they are
updating. It's an option that offers more flexibility, as users can
update from versions different from the latest one. It also plays well
with our system's flexibility, for instance, to change defaults between
a pre-release and a release. However, we can add some code to default to
the latest minor version, but we should keep that information in our
code, and that's a small burden for our update process.
Checklist: