Removes specific provider implementations #191
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
felixarntz
left a comment
felixarntz
left a comment
There was a problem hiding this comment.
I don't think we should merge this until we've ported all three of them elsewhere? There needs to be a smooth transition path, and as long as people can't get the providers elsewhere, their experience will just break without any reasonable path forward.
Marking as requested changes just until we're ready to merge this.
|
Agreed, @felixarntz! I just pushed the code to each repo along with a PR to review for each one. I'm going to update this composer to look at the implementing branch for each one for now so I can at least get the tests passing. |
|
(not a decision that needs to be made now or even prior to 7.0 but want to confirm y'all considered releasing from a monorepo a la WordPress/performance , especially as the number of supported will hopefully be more than 3 and repo overhead adds up. If not' might be a topic to bring up ones the near-term deadlines have passed) |
3 participants
This removes the specific provider implementations we've so far had for testing. The providers will be moved to their own repositories which can be used as standalone packages or installed as WordPress plugins. The plugins will be submitted to the WP plugin repository as well.
The packages have been added to this repository as dev dependencies, this is to use them for integration tests. Since there are no versions for them they're temporarily marked as
@devversioned.Here are the new repositories: