Building for Stability in OJS/OMP/OPS 3.3
This month we released OJS/OMP/OPS 3.3. These release packages were in development for nearly a year and represent a major step forward in our efforts to modernize the codebase and improve our release process. In this post, I’ll describe some of the key changes we’re making to the way we build software and how that will benefit our community.
In December, we published release candidates for each of our software packages. Release candidates are special packages that will be released ahead of a major version so that our community can test the new version on their own servers.
During the release candidate phase, PKP conducted intensive internal testing and community partners stepped up to conduct their own testing. Thanks to this effort, we were able to identify and fix several bugs that occurred in unique server configurations or customized installations.
At the same time, we published a change orientation guide to help technical staff, administrators and managers identify and prepare for the improvements in 3.3. We also published a Release Notebook for 3.3 to help developers update their plugins and themes.
These efforts made this release less painful and more stable for everyone in our community. In the future, we hope to reduce the length of this phase and make sure that more of our community is ready and able to test upgrades during this time.
If you’ve already upgraded to 3.3, you may have noticed how fast the upgrade process was. That’s because we’ve finally migrated away from ADODB, one of the oldest dependencies in our software suite.
We’ve adopted Laravel’s database library for interacting with the database, and this represents another step forward as we migrate more components of our software suite to this framework.
These improvements will make it easier to keep your installations of OJS, OMP and OPS up to date. The refactor of our update process, in particular, has solved a longstanding pain point for our developers, and will help them to focus on adding new features rather than supporting older releases.
This change won’t impact most existing code. However, we’ve removed a few of the old ADODB features that could lead to poor performance. If you’re a plugin or theme developer, you can read about how this change affects you.
Modern API and UI Library
We continue to migrate more of our application’s functionality to the REST API, in order to decouple our backend, make it easier to write third-party integrations, and build out more interactive and accessible UI components.
Our new submission file uploader is backed by a full set of API endpoints to perform CRUD operations on submission files (see the API reference). And our UI Library is growing quickly as we make use of Vue.js to modernize our editorial interface.
After we commissioned an accessibility audit of our default theme, we made a few changes to address the issues that were raised. If you have a custom child theme or have written CSS to style the default theme, you should review the accessibility changes.
Ready to upgrade?