Right, and this is already an existing problem specifically for the WooCommerce ecosystem.
The WooCommerce 2.7 release introduced new CRUD classes for all major data operations. This was a huge breaking change, enough that the team eventually decided to release it as version 3.0.0 to make it clearer.
Even sticking with WordPress, there is a lot that needs to be done to successfully upgrade from WooCommerce 2.6 to 2.7/3.0. See this guide for some examples, and that is definitely not an exhaustive list (here’s another more specific issue that can cause breakage during that particular WooCommerce upgrade).
So, as long as WooCommerce remains compatible with WordPress 4.9.x, ClassicPress doesn’t change anything here. A bigger issue for WooCommerce site owners is compatibility between WooCommerce and other plugins.
I’d suggest asking the WooCommerce team (via a GitHub issue) if they are going to keep support for WordPress 4.9.x in new versions, as many people will not be upgrading. If they can do that, then that makes our part much easier.
@parkerj the good news is that you have a lot of freedom to undertake this effort as you see fit. The bad news is that we wouldn’t be able to provide much official help or support right now, beyond giving you a place to put the code if you want, and maybe some commiseration mutual learning about all the things that need to be done to successfully fork large projects.
Are you thinking of forking WooCommerce yourself, or under the ClassicPress name?
If the former, well, you don’t need anything from us to get started
If the latter, we could use the https://github.com/ClassicPress-research organization and create a repository there. This is a semi-official place for experimental plugins that may one day be official recommendations from within the ClassicPress dashboard, or even integrated into the core software (not as likely in this case).
Either way, if you’re able to create and stay on top of a fork of WooCommerce, then kudos to you. And either way, what will ultimately determine the success of the project is whether members of the community choose to use it on their sites.
At this point the vote would be between “ClassicCommerce” and “something else”.
We can wait a day or two and see if other suggestions and a consensus emerge. It’s also not a big deal to change the repository name, so I wouldn’t worry about this too much until you’re ready to start actually changing the name in the code.