We’ve just upgraded a number of our OJS instances from v2.4.8 to v3.1.1. We ran the gauntlet of various database/code tweaks and survived to tell the tale. The problem we’re now facing is how to best deal with the plethora of patches that have come along since the OJS-3.1.1-2 tar file was released back in June.
The question I have is what would be required to replace the existing code directory with the git equivalent? I tried
I then replaced the config.inc.php, the public directory with those from the previous working v3.1.1-2 release and set the ownership of the files to apache.apache.
Unfortunately OJS did not run since the file permissions where still substantially different.
Is retrofitting git version control a reasonable thing to do and, if so, what’s the best way to go about it? (I’m a git neophyte)
check the OJS 3.1.1.4 release, it should include most of the patches you mention.
I too have had difficulties in handling the patches that come after the actual release. I can use git a bit, but there is no good guide on how to manage a production site and do upgrades there with git. With OJS it is especially hard because of the submodules and other dependencies. Probably when you learn it, using git for patching is easy but at the moment I just pick the most crucial fixes and apply them manually. It is doable when you only have one installation.
Simply installing the latest release would be much less intimidating. Nice to see that v3.1.1.4 has just became available.
In terms of installing the new code after a migration from a previous release, can I simply replace the current v3.1.1.2 code with the latest release and then copy over the config.inc.php file and the public directory? Would anything else be needed?
Close the server, delete everything else except config.inc.php public folder and of course files folder. Add the files from the new release. Set Installed to off from the config and the run php tools/upgrade.php upgrade. See the full package installation guide here: https://github.com/pkp/ojs/blob/master/docs/UPGRADE.md
That’s the approach I’ve been using as well. Very straight forward.
My confusion is upgrading between minor version releases. If I’m running v3.1.1.2 and wish to move to the latest v3.1.1.4 release, do I still run ‘php tools/upgrade.php upgrade’ ? I’m guessing yes but I just want to confirm.
well it could be that in this case it would work just by changing the files (have not taken a closer look) but I will definitely run the upgrade tools just in case.
A good practice is to have a test site where you upgrade a copy of the installation first.
I just ran a test and running the upgrade script is definitely the way to go. With a minor upgrade it takes no time at all. A preliminary look at my first updated instance indicates that the new version is running.