Before we reach the big 1.0 release of Listings core and our Jobs extension, we’re in a public beta phase. During this period of time, we’re actively developing on all parts of the code of our plugins. We might break backwards compatibility and probably will do so at least a couple times in the next few weeks. I’d like to take a moment and explain why we’re taking this approach and how you can benefit from it.
On breaking backwards compatibility
Breaking backwards compatibility is not something we like to do. We’d hate to change critical parts of the plugin, so that functionality is broken or fundamentally changed after you update one of the plugins in your website.
This is especially important when it comes to custom code, paid add-ons or third party code depending on code in one of our plugins. Breaking backwards compatibility is putting extra work on the todo lists of people maintaining code that relies on anything in the Listings ecosystem.
The whole WordPress ecosystem is also extremely focussed on maintaining backwards compatibility. It’s not often that a WordPress release breaks some kind of backwards compatibility and users have been told for many years to always run the latest and greatest release of everything.
It is up to the plugin developers in the ecosystem to make sure that their code is always compatible with the latest WordPress version and provide backwards compatibility. This is not easy. This is actually rather hard to do, in a lot of cases.
As soon as we have released a stable version of a plugin (starting with version 1.0.0), we intend to break backwards compatibility as little as possible. Before we hit that stable release, we have all the freedom to do with our code what we want.
Breaking backwards compatibility to make our plugins better
It’s in a developers nature to always want to improve their code. Looking back at code that I wrote a month ago makes me want to change so many things already. Most of the time that you’ll spend on improving, refactoring and optimising your code is not directly benefiting your customers, but will make the code easier to maintain. It’s always about finding a balance between quality code and actually adding new features and fixing bugs.
Since our plugins were born out of a fork of WP Job Manager, we’ve started working on code written by someone else. We picked WP Job Manager because it was a stable plugin, properly written and provided a solid foundation for our own plugins. That doesn’t mean that we agree with every decision made. We’ve changed quite a bit actually in the architecture, more than once to help us achieve the stable core and niche extensions setup that we had in mind.
Getting the community involved
Our plugins exist for a fairly short time now, but we’ve already had a lot of people express interest and contribute ideas. Our Slack channel (email us at email@example.com if you want to be invited) is buzzing every day with new ideas from the community. This varies from small fixes, to bigger undertakings. Some changes require breaking backwards compatibility. These changes require us to break backwards compatibility now, to ensure we don’t have to do this once the plugin is being used on a lot of production websites. We like to break things now, if there is a need for it.
Having this public beta phase where pretty much anything is open for change has been a great way for us to refactor code and try new things. Some ideas might fail, others will make it to the final product and prove to be a great change. Having the community backing us in all this is awesome and I love this way to build a product that we will all love and want to use on our websites.