Alberto Vena

Hey @tvdeyen! I think we can try to move this forward now. What about rebasing to try to have the test suite green? After we verified that there are no...

It makes sense but we should find a way to handle duplication of routes/controllers/views for users that will update `solidus` but not `solidus_auth_devise`, where we should also remove those files...

Also, we are thinking about moving all the controllers/views/helpers from solidus_auth_devise into core, keeping `solidus_auth_devise` as solely an authentication system, so it's better to wait until we finalize this decision....

By merging this PR stores will end up having the same route/action/view defined in both `solidus_frontend` and `solidus_auth_devise`. Do you see a possible solution to this?

Sure, I'm thinking that if a user upgrades to latest Solidus (that will include code from `solidus_auth_devise`) he will have the same code defined in both `solidus` and `solidus_auth_devise`. If...

@spaghetticode your proposed solution makes sense but no one can ensure us that user will update `solidus_auth_devise` after the `Solidus` update. We should think at least to some warning or...

@spaghetticode What about the routes? Don't we have a conflict of both core and solidus_auth_devise defining the same one?

> Solidus apps are complicated beasts with many interfaces (as ruby allows metaprogramming). Which parts of the interface do we consider stable API, and where do we allow ourselves change?...

I was discussing this offline with @waiting-for-dev and we realized that this still won't work with `update_column` and `update_all`. Not saying it's a trade-off we won't accept but reporting here...

I don't think there's a solution here, or I don't see it now. I think it's a matter to understand if we want to accept this trade-off or wait for...