We are in a funny situation: there's a command in the LTS branch that is not in the dev branch: set high-availability vrrp group Foo transition-script mode-force.
We need to either add that command to 1.3 as a dummy option that prints a warning about itself, or add a migration script. I'm inclined towards the former: keep as a dummy in 1.3, remove in 1.4.
There has been a long-standing problem with state tracking in keepalived. Old versions from the VyOS 1.1.x era could didn't have an option to re-read the config without doing anything. All configuration changes had to be applied by restarting the daemon, which caused groups to change their state.
That caused problems for people who use transition scripts. Making a configuration change meant daemon restart and a state change, and state change means transition scripts would fire... but a script running when it doesn't really need to is a problem. Sometimes a serious one if it sends notifications to admins, or changes the system configuration.
To safeguard against it, we've had a state tracking fixup. We kept state files and wrapped transition scripts in a script runner that would check if the state really changed, or it was just a daemon restart.
Then keepalived fixed that problem, and could be reloaded without any state changes. But our fixup remained. It's extra code, extra logic, and people can't force scripts re-runs by restarting the daemon. It also started causing problems with real transitions, as seen in T1350.
In 1.2 we've introduced a mode-force option to enable running transition scripts without our artificial state tracking.
However, in 1.3, the transition script logic got completely rewritten to account for keepalived's new behavior.