I have a key question regarding the migration from OJS version 3.3 to 3.5. I am reaching out to you as specialists, requesting a clear and as precise as possible answer, especially in the context of varied experiences from previous migrations (from version 3.1 to 3.3).
What is the most optimal upgrade path: do you recommend a direct migration from version 3.3 to 3.5, or is it advisable to include an intermediate step and upgrade first to version 3.4 (and if so – to which specific subversion)?
This question arises from previous experience, where issues only became apparent several weeks after migration—such as missing data in the database caused by an incomplete upgrade process. In such cases, reverting to a backup was no longer possible due to the continuous work of the editorial team in the production environment.
I would be grateful for a clear recommendation in the following scenario: if the editorial team is working on version 3.3.0-7 or 3.3.0-13 and plans to move to 3.5.0-3, should the system first be updated to the latest available version within the 3.3 branch (e.g., 3.3.0-22), and only then migrated to 3.5.0-3? Or does the intermediate version within 3.3 not affect the success of the migration?
Additionally, I would like to ask whether you are planning to develop a plugin similar to Acorn, which would allow restarting tasks and initiating statistics processing without requiring IT teams to configure cron jobs on the server.
Although configuring cron may seem simple from a technical perspective, in practice it often presents a significant organizational challenge. IT teams frequently do not have the time to implement such solutions, which hampers the smooth operation of the system.
The Acorn plugin was a very effective tool in this regard—its implementation allowed server-side processes to run automatically without additional configuration.
Do you recommend a direct migration from version 3.3 to 3.5, or is it advisable to include an intermediate step and upgrade first to version 3.4 (and if so – to which specific subversion)?
I recommend an upgrade directly from 3.3.0-x to 3.5.0-x. We’ll be releasing 3.5.0-4 very soon, by the way.
should the system first be updated to the latest available version within the 3.3 branch (e.g., 3.3.0-22), and only then migrated to 3.5.0-3? Or does the intermediate version within 3.3 not affect the success of the migration?
You can go directly from 3.3.0-13 to 3.5.0-x without an intermediate upgrade step at the latest 3.3.0-x build. We release all builds (the last digit of the version number) to be database-compatible, so upgrading from 3.3.0-13 to 3.3.0-22 would only affect the code, not the database.
Additionally, I would like to ask whether you are planning to develop a plugin similar to Acorn…
I think you’re referring to the Acron plugin. OJS 3.5.0-x has built-in job runner support and can achieve the same outcome without needing a plugin.
Regards,
Alec Smecher
Public Knowledge Project Team
I tried direct upgrading from 3.3.0.13 to 3.4.x.x. (can’t remember) in 2024 (well, actually our host was doing that. While they had succeeded with direct upgrades up to 3.3.0.13, something went wrong and the error logs pointed to email-related issues. Since our publishers were in the middle of preparing their next volume, I decided to hold off with that approach until 3.5 LTS comes out. @asmecher Is 3.5.0.4 the LTS version that you were referring to?
In the meantime, my curiosity got the best of me and I installed 3.5.0.3 on WAMPP server installed on a Windows 11 laptop where I got a sneak peek, but the emails were not going out even if the php scripts tested well. I felt encouraged to do the same on a subdomain using a cPanel, and opted to install it manually (instead of Softaculous, which I had been warned about)–that is, using the OJS user interface but without terminal access to the server.
Now I am in the process of figuring out how to migrate the databases and files 9and in which order). So you have any recommendations in this respect? Thank you in advance!
There’s a video on upgrading from 3.3 to 3.5 here.
OJS 3.5.0-4 will be released soon, and then the LTS flag will likely be attached to it afterwards. Watch for news on this via our usual channels; the status of the release will be clear on the download page.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks @asmecher I had watched the video before undertaking my installation projects but I could not really use the terminal as effortlessly as you demonstrated because my WAMPP installation was on a Windows computer and the second installation was in a cPanel in which I do not seem to have access to a linux terminal. Thanks for the update on the LTS, and I will test my new installation to see if the one-click update on the first screen is successful. Best! @asabhar
XAMPP and WAMP are popular local server solutions used for web development. While both serve the purpose of creating a local environment for testing and development, they differ in terms of platform compatibility.
Thanks, @deepvyas . Sorry about the typo whch I did not catch until now: I meant XAMPP, not WAMP. I used my laptop to get a sneak preview of the changes to the user interface and installation process. That is how I felt better about not using Softaculous, but it looks like the emails configured through php.ini and sendmail.ini are not going through even if the test.php script I used indicates that the email was sent successfully. So, the script must be working, except the major email systems are rejecting it because it is generated within a localhost environment. However, I still have the same problem with the OJS installation (done manually, not with Softaculous), as the emails are still failing…they are not even going out. Best regards, – @asabhar
and I installed 3.5.0.3 on WAMPP server installed on a Windows 11 laptop where I got a sneak peek, but the emails were not going out even if the php scripts tested well. I felt encouraged to do the same on a subdomain using a cPanel, and opted to install it manually (instead of Softaculous, which I had been warned about)–that is, using the OJS user interface but without terminal access to the server.