Apps currently set store loaders like this:

for _, upgrade := range Upgrades {
    if upgradeInfo.Name == upgrade.UpgradeName {
        storeUpgrades := upgrade.StoreUpgrades
        app.SetStoreLoader(upgradetypes.UpgradeStoreLoader(upgradeInfo.Height, &storeUpgrades))
    }
}

which needs to be changed if we were to not restart the binary. We need to set the next upgrade's store loader after the previous upgrade is complete.

Additionally, we would need to modify the pre-mature handler check in the upgrade module

// if we have a pending upgrade, but it is not yet time, make sure we did not
// set the handler already
if k.HasHandler(plan.Name) {
    downgradeMsg := fmt.Sprintf("BINARY UPDATED BEFORE TRIGGER! UPGRADE \"%s\" - in binary but not executed on chain. Downgrade your binary", plan.Name)
    ctx.Logger().Error(downgradeMsg)
    panic(downgradeMsg)
}

to allow setting upgrade handlers before their upgrade heights (as an option).

Seeing as this is currently unassigned, I'd be willing to take this on.

Changing the upgrade-info.json is an x/upgrade concern. This feature request doesn't seem to be an x/upgrade but mainly a Cosmovisor UX improvement.

I'd say we actually shouldn't change the upgrade-info.json but update cosmovisor to maybe read take multiple upgrade-info.json (maybe they should be annotated with a number, and cosmovisor read them in that order, or in another way i don't know)

Changing the upgrade-info.json is an x/upgrade concern. This feature request doesn't seem to be an x/upgrade but mainly a Cosmovisor UX improvement.

I'd say we actually shouldn't change the upgrade-info.json but update cosmovisor to maybe read take multiple upgrade-info.json (maybe they should be annotated with a number, and cosmovisor read them in that order, or in another way i don't know)

That makes sense to me. Would it be preferable to change the add-upgrade command to take a list of upgrades instead of just one:

add-upgrade <upgrade-name-1> <exec-path-1> <upgrade-name-2> <exec-path-2> ... <upgrade-name-n> <exec-path-n>

Or would it be better to add a new command entirely? Something like add-batch-upgrades?

I like add-batch-upgrades personally, as it isn't something you always need, best to split the concerns 👍
Are you willing to implement it?

I like add-batch-upgrades personally, as it isn't something you always need, best to split the concerns 👍 Are you willing to implement it?

Yep, I'm willing to take this on.

I like add-batch-upgrades personally, as it isn't something you always need, best to split the concerns 👍 Are you willing to implement it?

Hello, I spent some time trying to map out a way to implement this feature and wrote some prototype code, here's how I see it:

• Add a new command with the format: add-batch-upgrade <upgrade1-name>:<path-to-exec1>:<upgrade1-height> <upgrade2-name>:<path-to-exec2>:<upgrade2-height> .. <upgradeN-name>:<path-to-execN>:<upgradeN-height>, this will loop through all the arguments and call the already-existing AddUpgrade function (this function would have to be modified a bit so that it can save the upgrade-info.json file in an arbitrary location along with other minor changes). Once all the individual files are written, they'll all be concatenated to form a single file upgrade-info.batch.json.
• Start a watcher goroutine when cosmovisor run is ran that'll read the batch upgrade file and will watch the current height and swap out the upgrade-info.json file with the next one at the appropriate time.