I fear this might break forward compatibility for charms that still have upgrade-charm and config-changed hooks. Could this be amended to have the following logic instead?
Juju 2.0 Upgrade sequence:
- Look for upgrade hook, if fail
- Look for upgrade-charm, if fail
- Skip
Juju 2.0 Configure sequence:
- Look for config hook, if fail
- Look for config-changed, if fail
- Skip
This way charms developed with <=1.25 will still work in 2.0 since we don't have a max-juju-version field
Also, nitpick, since we're renaming things, `configure` seems more complete than `config` but that's just the color of the shed I'd prefer.
I fear this might break forward compatibility for charms that still have upgrade-charm and config-changed hooks. Could this be amended to have the following logic instead?
Juju 2.0 Upgrade sequence:
- Look for upgrade hook, if fail
- Look for upgrade-charm, if fail
- Skip
Juju 2.0 Configure sequence:
- Look for config hook, if fail
- Look for config-changed, if fail
- Skip
This way charms developed with <=1.25 will still work in 2.0 since we don't have a max-juju-version field
Also, nitpick, since we're renaming things, `configure` seems more complete than `config` but that's just the color of the shed I'd prefer.