In short
The strategy 1 is a direct upgrade.
The strategy 2 is a sequential upgrade (example by RedHat) or successive release upgrade (example MongoDB or MySql, at least in former versions). But be careful, since there is no authoritative definitions or commonly accepted terms.
Terms might be misleading
The terminology related to upgrade is tricky and often misleading.
Take the example of Robert's incremental upgrade :
- For any agile developer, solutions are delivered in increments. So it could be tempting to see successive versions as the natural increments.
- However in the Google patent referred to by Robert, and more precisely in the section about prior art, incremental is used to refer to patches: it is opposed to full replacement of executables of one version by the executables of the another one.
- So incremental upgrade might refer to very different things and have different meaning for different people. And it does not address your question, since the granularity of the increment is not defined: is it patch by patch or version by version ?
Take the example of Dr.Brown's cumulative upgrade:
- Strategy 1 is clearly non-cumulative
- Strategy 2 can be cumulative if you add up patches until you reach the desired version. However, you can also replace each version by the next, so it's a succession of substitution and nothing accumulates.
- The problem with cumulative is that it has a technical connotation of accumulating small things. Again, it can mean different things to different people.
Restrict yourself to commonly agreed terms
The following terms are widely accepted and used:
- The upgrade path describes the way to upgrade from a source version to a target version
- A direct upgrade is when you can go directly from source to target, without using intermediate versions.
- Intermediate versions are versions that are on the path
Any other more precise terms are subject to caution. Even in your own example, it is not clear if you can skip minor versions (between 8.0 and 9.0) and if the successive versions apply only to the same versioning level.
This is why the biggest vendors use extensively the upgrade path, make full sentences to describe how this path looks like in general, and present the possible path in nice matrices (which also allow to cope with the many exceptions due to change of strategy in older versions).