We currently have multiple different approaches for managing versions of things in BlueOS, which is unintuitive, and means some services miss out on functionality that seems quite obvious.
In particular:
BlueOS-core versions can be updated in the basic BlueOS Version page, and selected and installed (including with selection of the dockerhub repo) and removed when in Pirate Mode, and a failed startup automatically falls back to a known 'factory' image, which currently cannot be (nicely) changed
BlueOS-bootstrap can have new versions installed to match the currently active BlueOS-core image, if it's newer than the bootstrap version
This one is perhaps reasonable, just noting it for completeness
BlueOS Extensions can be installed and updated through the manager, but there's no interface option to switch between installed versions, or to flag versions that are no longer wanted and can be deleted
This is a poor user experience, and extra important once people can pay for extensions, because if a user updates to a version they only have temporary access to (or to a broken/buggy version) then they should be able to restore back to one they have full access to / that they know works
Autopilot firmware versions are not stored or switchable between
This is extra relevant now that PX4 is getting integrated, because a user could want to try a different firmware type but then be able to switch back to their normal known good one (although that may also happen as-is when trying out a beta firmware or whatnot)
Support is currently limited for switching between different firmware types that are compatible with an available flight controller board
Expected or desired behaviour
Ideally we would have similar features available for everything that has versions, and also have consistent interface elements for managing those features, so that there's less to learn, and the interface feels familiar and trustworthy to users.
Prerequisites
[X] I have checked to make sure that a similar request has not already been filed or fixed.
Current behaviour
We currently have multiple different approaches for managing versions of things in BlueOS, which is unintuitive, and means some services miss out on functionality that seems quite obvious.
In particular:
BlueOS-coreversions can be updated in the basic BlueOS Version page, and selected and installed (including with selection of the dockerhub repo) and removed when in Pirate Mode, and a failed startup automatically falls back to a known 'factory' image, which currently cannot be (nicely) changedBlueOS-bootstrapcan have new versions installed to match the currently activeBlueOS-coreimage, if it's newer than the bootstrap versionExpected or desired behaviour
Ideally we would have similar features available for everything that has versions, and also have consistent interface elements for managing those features, so that there's less to learn, and the interface feels familiar and trustworthy to users.
Prerequisites