Hi @naoliv,
If I manually apply security patches and fix issues that affect only the features I use, there would theoretically be no need to perform a formal upgrade, correct?
If you’re staying within the same line of releases (e.g. 3.3.0-5 to 3.3.0-15), then there is no need to execute the upgrade script – you can just update to the latest code. We maintain a high level of stability and compatibility within releases from stable branches like 3.3.0-x.
If you’re interested in e.g. back-porting features from 3.4.0-x or 3.5.0-x to your 3.3.0-x installation, then I don’t recommend that; a lot of renovation goes into a major release, and getting that code to work with your 3.3.0-x installation will be tough work and quite error-prone.
If, for some reason, I just want to set a specific OJS version in the database, where exactly could I do that?
The current OJS version is in the database as follows:
SELECT * FROM versions WHERE product='ojs2' AND current=1;
If I change the version directly in the database, could that affect the upgrade process in any way?
Yes – it’ll affect the upgrade scripts. OJS uses the current version in the versions table to determine what scripts and migrations to run on upgrade (see dbscripts/xml/upgrade.xml for how this is choreographed), so altering the entry in versions will affect which scripts get executed on upgrade.
As a general recommendation – it can become a lot of work to selectively patch features. I would strongly recommend staying with the latest in your line of releases, and managing any modifications you might have, rather than staying with an old release and back-porting patches. You can use tools like git to manage modifications very effectively.
Regards,
Alec Smecher
Public Knowledge Project Team