…first and foremost. CP has very little number of devs able to really take care of what managing a whole release is like. Dividing them to do everything at once isn’t logic at all.
About compatibility there are two types:
-
compatibility with WP 4.9 to ease the path of the migrating users
THIS ONLY REFERS TO V 1 THAT IS AN LTS AND IS USED AS AN ENTRY POINT AND AS A LIASON WITH V2 THAT WILL INTRODUCE BREAKING CHANGES (WordPressers will entry from WP 4.9 (or whatever version they have that we support migrating from) to CP V1, that will allow them to have a secure path to V2 and following - migrating from WP to CP V2 directly is NOT going to happen). -
compatibility CP with CP
That is meant to ensure that if I am on V1 and wanting to upgrade to V2 my site won’t get bonkers when I hit upgrade. Basically as I have understood the WP autop issue stands in this category because core of V1 relies on it and instead to be able to ship the editor V5 in CP V2 we need to do something to core so that it doesn’t need WP autop any more (or if it does it works with the upgraded editor) and this if done well is going to result in me upgrading to CP V2 as soon as it ships without fear of my site breaking into pieces.
As of now V1 has some issues we need to complete to be able to use it as a bridge. And a bridge is needed because there aren’t only the users discovering CP firsthand, but we need to consider also the ones wanting to migrate to CP from WP.
The second type of compatibility (or better: make breaking changes in a way they don’t break sites) is what CP was born for.
GB is a breaking change (it is a very different editor). It was introduced and broke sites. MANY MANY MANY SITES.
It could have been implemented slowly, better developed (WP has the manpower to do so!)… And in that case it woukd have being a breaking change DONE RIGHT bringing a very new feature without disintegrating people’s hard work on building their sites.
CP wants to introduce breaking changes without throwing sites in the garbage.
Breaking change doesn’t mean:
“Oh I want to develop a new feature, I will throw it in without considering the outcomes, I don’t guarantee it works, if it breaks your site I don’t mind because it’s your fault for upgrading”
It means:
“Here, I am developing a cool new feature that is very different. I will release it in V2 since it’s a breaking change and I am taking my time to release it to ensure that you can upgrade from your V1 to the new V2 safely. If you don’t like the new feature, please do know that you can use V1 safely since it is an LTS that will receive security updates for very long time and that if you at any time change your mind and want to upgrade you can also do so without issues because upgrading is seamless from V1 to V2.”
That said: people are already working on both V1 and V2.
It was decided that V2 will be all about the editor upgrade and the introduction of plugin/themes directory.
The directory has priority and is a VERY MAJOR CHANGE that will open the doors to the development of an ecosystem (devs will have a way to deliver themes and plugins and their updates).
To integrate it into CP there are two things needed: working on refining it and making it really something amazing (and this means knowing Laravel since as far as I understood it is made with Laravel, love and efforts) and the part where core code gets changed to implement it.
@anon66243189 is leading the effort of making the directory amazing and @james is leading the effort to implement it into core when ready to ship.
V1 is all about backports of useful things like SECURITY FIXES and smaller tiny features that are “non breaking” (it is possible to include in V1 some features like the login page customization since things like that don’t break sites when introduced and so there is a number of people following backports of security as a priority and these little nifty things as a way to show that even if V1 is only a bridge LTS it is making smaller improvements for people who want to stick with it forever).
Now, if you are a dev and you want V2 to happen this is fantastic!
Please help to include the amazing directory into the core in a way it doesn’t break my site when I hit upgrade.
The editor upgrade is scheduled to happen after the directory inclusion in one of V2 point releases, so you will have to work on it after completing the directory.
If instead you think you are better at keeping up with backports, that is happening for V1 so you can lend a hand there!
The slowness everybody sees is due to the fact that our few devs are working on both versions keeping them moving at the same time.
If MORE DEVS decide to roll sleeves up, then having V1 team and V2 team is feasible.