This reverts commit c658189cd21db1340aa6bf40e2b1cc80d8b53191.
On #36, we bumped the solidus_frontend version to 4.0.0.dev. However, because of a mistake, we merged that PR on the v3.4 branch instead of master. That was incorrect because, like upstream Solidus, it's the master branch the one that's tracking the next minor or major release.
However, before doing that we already had released solidus_frontend v4.0.0.dev to RubyGems. To avoid commits with different SHA on the released version vs. what's on this repository's master branch, we directly push to solidus_frontend instead of going through our regular merge PR flow. We could do that because both branches were the same before that commit and the alternative implied ending up with an inconsistent state that could confuse somebody, or releasing v4.0.1.dev plus bumping Solidus upstream for a dependency that is going to be removed from the meta-gem very soon.
This reverts commit c658189cd21db1340aa6bf40e2b1cc80d8b53191.
On #36, we bumped the solidus_frontend version to 4.0.0.dev. However, because of a mistake, we merged that PR on the v3.4 branch instead of master. That was incorrect because, like upstream Solidus, it's the master branch the one that's tracking the next minor or major release.
The side effect of that was that CI on extensions was failing because of not finding the matching solidus_frontend, as when they test Solidus master they also pull solidus_frontend master branch. For example, from https://github.com/solidusio/circleci-orbs-extensions/blob/master/solidus_dummy_extension/Gemfile#L6-L10:
Accordingly, we needed to update the master branch from this repo to track 4.0.0.dev. See https://github.com/solidusio/solidus_frontend/commit/c658189cd21db1340aa6bf40e2b1cc80d8b53191.
However, before doing that we already had released solidus_frontend v4.0.0.dev to RubyGems. To avoid commits with different SHA on the released version vs. what's on this repository's master branch, we directly push to solidus_frontend instead of going through our regular merge PR flow. We could do that because both branches were the same before that commit and the alternative implied ending up with an inconsistent state that could confuse somebody, or releasing v4.0.1.dev plus bumping Solidus upstream for a dependency that is going to be removed from the meta-gem very soon.
Summary
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: