- there are two rough stages of software that come to mind:
- given an experimental/in-dev tool, you'd want a community that cares about the tech & is sufficiently excited about it & tolerant/forgiving enough of bugginess. in this case, frequent breakages and upgrades are reasonable
- if a community wants a tool that "just works", a stable tool is best. a tool that's mature enough that it basically NEVER needs to be updated again after the initial install, and even if upgraded, are just bug fixes that don't break any compatibility in the data or protocol layers
- Mapeo is in category 1, but is often being deployed in category 2 situations, which seems like a recipe for disappointment & frustration. expecting an immature tool to be a mature tool is going to be frustrating
- ideally we'd do our best to maintain backwards compatibility, but it's worth considering how frequent breaking changes are,
- i.e. if we release a data/proto breaking change every 3-5 months, it doesn't make sense to spend weeks trying to make a release backwards compatible
- it makes more sense to optimize the upgrade path
- so, upgrading:
- frequent upgrades seem unavoidable given experimental/in-dev software
- so the question instead becomes: how do we make upgrades that are all of:
- easy to deploy + propagate over all devices in a community, and
- is very reliable (the upgrade mechanism) and not going to leave the device in a broken state
- make rolling back to an old version very easy
- like gregor pointed out, a p2p ugprade mechanism will need to be
- extremely air-tight (no bugs)
- ideally, never need to be upgraded/changed itself
- so, quality design will be very important for the p2p upgrade mechanism
- it should operate separately from the current proto and data layers, and live in isolation, so that any data or proto changes in the app won't compromise the upgrade mechanism
- the app breaking/crashing shouldn't be able to prevent or compromise the upgrade mechanism
- being able to roll back is very important, otherwise folx may upgrade to a new version, experience bugs that prevent them from using the app, and be stuck in that state until we manually fix it
- this can mean keeping around previous APKs or EXEs of MM/MD in a simple database
- it's important to make the current version very visible, so the community can coordinate a clear "let's all get back onto this specific version", otherwise some folx may rollback, other may not, and some may rollback farther than others
- substack: a hyperdrive for app payloads could work. with a folder structure $VERSION/$ARCH; and you just pick a version of hyperdrive and don't upgrade it
- is the version management component its own electron app, or something you bake into your own app? the former is nice b/c it gives full separation -- you don't even have to ever update the electron version. but it's also another 70mb+ for ANOTHER electron app; also /w an electron startup cost x2 now
- you COULD bundle it into your own app, and just boot the version manager before you do ANY of your app's stuff though, and that'd be ok so long as you don't accidentally upgrade to a version of electron that breaks the versioning tool
- since a device breaking down in the field is super undesirable, i'm leaning toward it being its own separate program
- maybe fork https://github.com/staltz/dat-installer
- android + apks are a whole other can o worms
- but needing people to manage two apps for mapeo on their phone is inviting problems
- looks like an apk can update itself:
- such an app would also ideally give hints around what version clusters share DATA compatibility (you won't lose your local db) and PROTOCOL compatibility (you'll still be able to sync /w others)