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.