Flatpak 1.0 has happened a while ago, and we now have a stable base. We’re up to the 1.0.3 bug-fix release at this point, and hope to get 1.0.x adopted in all major distros before too long.
Does that mean that Flatpak is done ? Far from it! We have just created a stable branch and started landing some queued-up feature work on the master branch. This includes things like:
- Better life-cycle control with ps and kill commands
- Logging and history
- File copy-paste and DND
- A better testsuite, including coverage reports
Beyond these, we have a laundry list of things we want to work on in the near future, including
- Using host GL drivers (possibly with libcapsule)
- Application renaming and end-of-life migration
- A portal for dconf/gsettings (a stopgap measure until we have D-Bus container support)
- A portal for webcam access
- More tests!
We are also looking at improving the scalability of the flathub infrastructure. The repository has grown to more than 400 apps, and buildbot is not really meant for using it the way we do.
What about releases?
We have not set a strict schedule, but the consensus seems to be that we are aiming for roughly quarterly releases, with more frequent devel snapshots as needed. Looking at the calendar, that would mean we should expect a stable 1.2 release around the end of the year.
Open for contribution
One of the easiest ways to help Flatpak is to get your favorite applications on flathub, either by packaging it yourself, or by convincing the upstream to do it.
If you feel like contributing to Flatpak itself, please do! Flatpak is still a young project, and there are plenty of small to medium-size features that can be added. The tests are also a nice place to stick your toe in and see if you can improve the coverage a bit and maybe find a bug or two.
Or, if that is more your thing, we have a nice design for improving the flatpak commandline user experience that is waiting to be implemented.
One thought on “Flatpak, after 1.0”
What could potentially be interesting for us (VirtualBox) would be a way of using the runtime without the sandbox. We currently run setuid, which is a bit of a blocker for sandboxing (and we load kernel modules anyway).
Comments are closed.