Long term planning, refactoring, breaking backwards compatibility and new features

[coenjacobs]

It's been a while since I've given this project the attention it deserves. Today, I've checked all fixes that you all have contributed in the past couple months and pushed everything that was ready in the 1.1.0 tag that is now available. If no bugs are found, that is going to be the last 1.x release for this library.

To push this project further and make it even easier for plugin developers to enforce a minimum and recommended version of PHP, some fundamental parts of the library need to change. The next version of this library will be version 2.0 and is going to be a full overhaul.

Refactoring is going to be the core purpose of this new release, where some of our long standing issues will take priority in finally being resolved.

Roadmap for 2.0

• #8 Internationalisation has been on our radar since pretty much day one. Since this library will be bundled inside a plugin, it's impossible to ship our own textdomain. In one of the comments of earlier this year, @grappler proposed passing the strings to the main object, so we can translate them using the textdomain of the plugin itself. I'm a fan of this approach and want to make this happen for 2.0.
• #22 Hide recommended version admin notice could perhaps be part of a 1.x feature release, but it's easier and cleaner if we do this at the same time as we do the meat of the refactoring in #35. Splitting the functionality up in multiple smaller parts makes the code cleaner and easier to refactor, but also more prone to class collisions (proven by #37).

I'd like to continue using this issue as a discussion platform, where we can toy around with some new ideas or discuss the refactor in general. As soon as the dust has settled, I'll make sure the changes required for this release are properly specced out in separate issues.

[GaryJones]

Does https://github.com/Yoast/whip have the same overall goals as this repo?

How can the two efforts be aligned?

[coenjacobs]

@GaryJones I think both libraries have similar goals, yet I think both have a place in the ecosystem. I personally think that the independent position WPupdatePHP is in, is favorable for a lot of situations. The site of this project provides a lot more information and is purposefully designed to be independent from any commercial or branding influences. Both libraries give developers the opportunity to require a modern PHP version, which is a good thing. I think both projects have slightly different angles to approach the problem at hand.