Allow user to easily convey "latest minor version" for a known target major.
Sometimes a user just wants the latest minor on a major series, such as v13. So allow customer to just say 13 and in such cases, we just assume the latest minor version and then go about finding the upgrade paths.
In effect this should work too:
python getRDSUpgradePath.py 10.13 13
Currently though, we require customer to know which minor is latest. for e.g. v13.9 or v13.10. For e.g. this is today's experience (avoidable).
$>python getUpgradePath.py 10.13 13.11
..Target Engine Version is not supported in RDS: 13.11
$>python getUpgradePath.py 10.13 13.10
..Target Engine Version is not supported in RDS: 13.10
$>python getUpgradePath.py 10.13 13.09
..Target Engine Version is not supported in RDS: 13.09
$>python getUpgradePath.py 10.13 13.9
.........................
Upgrade path not found. May be you want to increase hop-count and try again.
$>python getUpgradePath.py 10.13 13.9 postgres 2
.........................................................................................................................................................................
Upgrade Steps / Hops: 2
Path: ['10.13', '12.3', '13.9']
Path: ['10.13', '11.18', '13.9']
Path: ['10.13', '10.23', '13.9']
^^ 3 upgrade paths found
Allow user to easily convey "latest minor version" for a known target major.
Sometimes a user just wants the latest minor on a major series, such as v13. So allow customer to just say 13 and in such cases, we just assume the latest minor version and then go about finding the upgrade paths.
In effect this should work too:
python getRDSUpgradePath.py 10.13 13
Currently though, we require customer to know which minor is latest. for e.g. v13.9 or v13.10. For e.g. this is today's experience (avoidable).