@G.S.1 How do you feel about the epochs feature, that enables us to release software and control exactly which specific revisions of a snap someone should update to so that data migrations happen safely and correctly, and in a tested path.
Or how about base snaps, a feature that we’re eager to land as it will enable arbitrary base filesystems instead of what is fixed by the core snap.
Or layouts, enabling people to define arbitrary filesystem layouts inside their own snaps without affecting the rest of the system. Yet, without losing the read-only, compressed, atomic nature of snaps.
How about multi user support, which will allow snaps to support multiple users and collaborate with the host system in that regard.
Snapshots… We’ll have the ability to perform multiple data snapshots for every snap, with nice semantics on removals.
Or… being able to install the same snap multiple times, in parallel. I’m looking forward to that one, which allows a single snap to be present in the system multiple times, with independent identities. Say, two different versions of your preferred database, for example, to satisfy different applications.
Statistics… Health-checks… Staged deployments…
.
.
So… that list is real. This is part of what we’re focused on right now. It’s also the essential reason why I cannot possibly satisfy the request for even more details about federation today than the extensive responses provided above, which already includes the statement you are asking for and much more. That’s also true of any other large feature that is not on our roadmap already.
Over the next several months, you’ll see everybody in the team working hard to design, and then implement, review, and land those features and many others that continue to focus on having a software delivery platform we’ll all be happy to work with.