Easy and problem free self-installing OJS software upgrades

Hi @gail,

Don’t worry about the feature request format posted above – let’s work through the individual errors you encountered on your other thread and I’ll give a general perspective on upgrades.

The difficulty in upgrading is a general problem for our community, and it’s twofold:

  1. The community tends not to have the tech resources required, and
  2. The upgrades are not as easy as they should be.

We’ve talked about upgrades quite a bit during our last dev leads webinars; the next of those is on Feb 5th, 8am Pacific time, if you’re interested.

The first problem is unfortunately just the nature of the beast. Historically our community is grassroots,
which means little institutional support and a lot of personal initiative. We are seeing a lot more institutional uptake recently, which is great – the journals get better support through institutional IT, and it’s likelier that the institutions themselves can become contributors to the software; the latter is especially important is it magnifies the effective size of the development team. We are historically a small team, and have been lucky to gather a large user community, but this has made it a challenge to match the resources to the needs. The end result is that we have a lot more work than developers, and parts of the system – such as upgrades – have not gotten the polish they deserve.

But fundamentally OJS is self-hosted free/open source software, and it’ll require some IT skill to run. Some aspects of it will be harder than others, and unfortunately upgrades are one of the tougher aspects.

On to the second point: that upgrades can be hard to do. This has been a long-standing problem for us on the dev team as well, as it means that the community runs old software, and we often have to support years-old software (and identify years-old bugs). The more the community can stay up to date, the better it is for everyone, and difficult upgrades are an impediment.

This might run counter to your experience, but OJS 3.3 and 3.4 have received a lot of effort in cleaning up the upgrade process. The effects of this work will be more visible in future releases, once you’ve made that leap – future upgrades will be easier. OJS is mature software and a lot of upgrade challenges have to do with inconsistent data in the database that has accumulated over the years, and both 3.3 and 3.4 attempt to clean that up during upgrades, and add stricter rules so that future inconsistencies won’t be possible.

We’ve often talked about Wordpress as an example of software that can be kept up-to-date relatively painlessly, and we are moving in that direction. But one major difference between Wordpress and OJS: OJS is huge software by comparison. Wordpress can revamp its entire database in a very short time – it’s a dozen database tables or less – and OJS has over 100. So it’s a much larger task, both for the dev team and for the upgrade toolset.

Just a quick FYI – part of our work on upgrades has been to distinguish between Long-Term Support (LTS) releases and non-LTS releases. OJS 3.3 is an LTS release, but 3.4 is not. For groups without a lot of tech resources to draw on, it might be best to wait for the next LTS release and go straight there from 3.3. LTS releases are maintained for a window of 3-5 years.

Hope that helps at least to understand the challenges!

Alec Smecher
Public Knowledge Project Team