Can anyone help me to understand what is Major, Minor, Revision, and Build mean when we see the version history of ojs using the administration area?
Sure. As far as I know there is no official documentation about the version naming but it will probably be addressed soon.
This “MAJOR.minor.revision-build” is the way PKP uses to name a version and is a variant of something called “Semantic versioning”.
To make it clear, let’s take some real examples and see how they look like:
| Version tag | MAJOR | minor | revision | build |
|---|---|---|---|---|
| 2.4.8-5 | 2 | 4 | 8 | 5 |
| 3.2.1-4 | 3 | 2 | 1 | 4 |
| 3.3.0-7 | 3 | 3 | 0 | 7 |
| 3.3.0-8 | 3 | 3 | 0 | 8 |
The idea behind semantic versioning is, each position express “how complex are the changes introduced” so it let you know what you can expect when you upgrade from one version to other.
- MAJOR number will change when you make incompatible API or DB changes (aka. upgrade will be very difficult or impossible).
- minor version when you add functionality in a backwards compatible manner (aka. upgrade will include “breaking changes” but will be possible).
- revision version with changes that improve existing functionalities (aka. don’t expect much problems, but set aside some time)
- build version when for bug and security fixes (aka. upgrade will run smoothly).
So, according to this:
- Expect a nightmare if you like to jump directly from 2.4.8-5 to 3.3.0-8 (in fact, this is not possible and you will need a “pit stop” at 3.2.1-4).
- Keep calm and take a chair to jump from 3.2.1-4 to last 3.3.0-8.
- Or upgrade whenever you like (except Friday :-P) from 3.3.0-7 to 3.3.0-8 because it will be a piece of cake.
Of course, Murphy is everywhere… so take this as something orientative and always backup before any upgrade.
Cheers,
m.
2 Likes
@marc thank you. I will try to digest. so is it good to jump from 3.1.1.2 to 3.3.0.7 and even then later 3.3.0.8 ?
I would recommend always stop in “3.2.1-4” before going to any 3.3 version… and after this, won’t be much a big deal if you go directly to 3.3.0-8 instead of -7.
In other words, for your example, I would go with the following upgrade path: 3.1.1.2 > 3.2.1-4 > 3.3.0-8
1 Like
@marc unfortunately, we already upgraded and in the middle of the work, how to recover lost stuff then? though site was compromosed and most of the files were even not found in backup and their relation to db was also corrupted… My question is:
leaving our installation as it… I mean we are on 3.3.0.7, What we are doing is now population the compromised recoverd or record having issues to keep site up and running… so what will be future consequences then? in this way we are safe further if we redo all data /mal formed data / compromised data?
I’m so sorry to hear this. This is why I always say that we must “backup before any upgrade”.
In fact, I will never recommend upgrade directly to a production site… the safe way is do a backup, recover in a testing server (so you know backup is fine), test the upgrade there and when you are sure… backup again and do the real upgrade.
Unfortunately I can’t answer your question because the upgrade could stop anywhere in the process.
I would recommend go to a testing machine and install a clean version of 3.3.0.7 to compare de DB structure. If they are the same you are not safe (data could be corrupted, files missing…) but is better than discovering the script didn’t finish migrating the DB structure.
But before anything, please… make a backup and test it to be sure you can (at least) go back to this point.
1 Like
@marc I am sorry to but wanted to share my experience here… its all working nice till 3.2.1.4 you can say, but as soon as I upgrade to latest, it start behaving the same way (without or without 3.2.1.4 upgrade)
any solution?
Sorry @doneforyou… scenario is now too random to help you without taking a look to the specific installation so I can help you further. May be somebody from the pkp support team can take a look to discover where is failing, but you will need to report it in more detail.
I recommend you open a new post, summarize what you did (ie: upgrade from 3.2.1-4 to 3.3.0-7?), detail the version where you got the error (ie: 3.3.0.7?), the action you are doing (ie: when I visit my home…) and post the exact error you get. You will need to take a look to your logs to discover the error.
Cheers,
m.
@marc ok what If I create a staging environment to the version things were working atleast? how can I share the username passwords privately/securely?
In my other thread on discussing, we are adopting and repopulation the fauly records, but the faulty record start showing in active queue while new submission works great till galay and this is what we are working on the old records - The system was hacked and somehow compromised, so we are lost you can say.
Previously there was a delete submission option but I cant see now in latest version… what sql query I can run to remove the specific submission from the author (author may have several submission but we wanted to remove specific using submission id as a primary parameter)
Create a staging environment is always a must.
If the question is “could you help me to find the error in this environment” I’m sorry, but I can’t.
I’m sharing what I learn from others but digging into this will take too much time and I’m helping in the forum as a volunteer.
Let me advance that, if the problem is too complex, even PKP won’t be able to help you for free.
They offer forum support because they believe they have to help the community, but heavy/complex tasks need professional help.
In my other thread on discussing, we are adopting and repopulation the fauly records…
Please, post the link to the other thread so we can talk about the issue there.
Talking about the same in different posts is against the netiquette of the forum.
The system was hacked and somehow compromised
ÂżWhat vector of attack did they use? ÂżHow do you know it was hacked?
I can’t remember any hack when to an OJS if this is up to date (don’t need to be last 3.3.x, it could be stable-3.2.1 if you don’t want to jump into 3.3.x branch).
Cheers,
m.