Upgrade paths shouldn't consider the last digit

[rohityadavcloud]

This is probably the 2nd time this has happened. As per our community discussion, the last digit in a version is for security/patch releases and it shouldn't require any upgrade path etc.

From a.b.c.d, the upgrade path logic shouldn't consider .d.

ISSUE TYPE

• Bug Report

COMPONENT NAME

DB, Upgrades

[rohityadavcloud]

One solution is to consider any a.b.c.x to use same upgrade map/list for a.b.c.0 (assuming it exists).

[weizhouapache]

can we also consider the upgrade from a lower version but released later to a high version ?

for example, upgrade from 4.17.2.0 to 4.18.0.0 (assume 4.17.2.0 is released after 4.18.0.0) ?

[DaanHoogland]

not sure if that is feasible given the implementation byt certainly worth having a look @weizhouapache

[hooklee2000]

@weizhouapache Maybe we can add a field such as “next_upgrade_class” in version table of mysql. later version 4.17.2.0 known 4.18.0.0 then fill the field as "com.cloud.upgrade.dao.Upgrade41700to41800". When upgrade from 4.17.2.0 to 4.18.0.0 (assume 4.17.2.0 is released after 4.18.0.0) , firstly get the field's value then new Instance the class and execute.