0install: Roadmap

Roadmap

This document explains what we've done and where we're going with future versions.

History
Current and future plans

History

This is a quick overview of the major features added to Zero Install. It focuses on features available to feed authors, who want to know which features they can safely use while supporting users on older distributions.

2005 (versions 0.1 to 0.17)

Zero Install was created in 2003 as a distributed network filesystem. In 2005, it was redesigned to the current "injector" system. Feed files from version 0.2 can still be run using the current version.

2006 (versions 0.18 to 0.24)

Major features added in 2006:

Support FTP downloads of archives.
XML signatures (not just plain GPG).
The <recipe> element allows combining multiple archives.
Restrictions on suitable versions of dependencies, using the <version> element.
Support for other secure hashes (not just sha1).
Support for extracting from RPM, Debian, Autopackage, zip and Cabinet format archives.
Compile a binary from source.
More flexible version numbering (e.g. "1.2-post7").

2007 (version 0.25 to 0.31)

Extracting from .tar.lzma and .tar (uncompressed) archives.
Background checking for updates.
Automatic secure sharing of downloads.
Bug reporting.
Native package manager integration for Debian and RPM systems.
Implementation bindings (<environment> directly inside <implementation>).

2008 (version 0.32 to 0.37)

Mirrors for feeds.
Manage applications added to the menu (GNOME and KDE).
Multi-arch support.

2009 (versions 0.38 to 0.43)

Support for Fink (Mac OS X).
Easier compile-from-source ("Automatic" mode).
Key information server.
<needs-terminal> supported.
Downloading feeds over HTTPS.

2010 (versions 0.44 to 0.51)

Download progress bars in console mode.
Canonical CPU type names.
Gentoo, Slackware and FreeBSD Ports integration.
Apple dmg-format archives can be used on Mac OS X.
Specify distribution name in <package-implementation>.
Support for multiple hash algorithms for a single implementation.
Added 'local-path' attribute.
SAT solver handles complex version requirements.
Select implementations based on user's locale.
Support for PackageKit (prompt the user to install distribution packages where necessary).
Initial Windows support.
The <command> element allows passing extra arguments.
The <runner> element allows specifying the interpreter.

2011 (versions 0.52 to 1.5)

The "0install" command.
The value attribute for <environment>.
Recursive use of <runner>.
Better defaults for approving new keys.
A Mac OS X binary package.
Improved Python support.
0install 1.0 final!
<environment separator=...> attribute.
Optional dependencies (but didn't work reliably until 1.7).
<executable-in-var> and <executable-in-path> bindings.
Use threads instead of sub-processes for downloads (more efficient).
Update to network-manager 0.9 API.
MacPorts distribution support.

2012 (versions 1.6 to 1.14)

Arch distribution support.
Explicit "file:" prefix for interface URIs.
Optional dependencies work (introduced in 1.2 but buggy).
Cygwin distribution support.
<replaced-by> element.
<command> inside <package-implementation>.
"Explain this decision" feature.
"POSIX" architecture (everything except Windows).
Limits on the number of concurrent connections to a site.
Support for apps.
Better Windows support from Python (so tools like 0compile work out of the box).
Support for programs such as cmake that can't cope with "=" in pathnames.
Support for Python 3 and GTK 3 (in addition to Python 2 and GTK 2).
The <restricts> element.
The recipe <rename> step type.
Mirrors for archives.
Support for headless servers (0install-core package).
Improved diagnostics when a solve fails.
The 'if-0install-version' attribute.
The --version EXPR and --version-for URI EXPR command-line options.
Disjoint version ranges (e.g. "2.6..!3 | 3.2.2..").

2013 (versions 1.15 to 2.5)

Shell tab-completion.
"0install show" command.
<requires distribution='...'>.
<for-each> for argument expansion.
0install 2.0 released!
"0install search" command (searches the default mirror).
<remove> recipe step.
<binding> for custom bindings.
.xz compressed archives.
Relative archive paths in local feeds.
Rewrite in OCaml (fully compatible but 10x faster).

2014 (versions 2.6 to 2.8)

OCaml port completed.
JSON API (0install slave)
Separate 0install and 0install-core packages in Debian, to allow installing on headless servers without pulling in any GUI dependencies.
Support for <requires source='true'/> dependences.
Getting credentials from .netrc.

Current and future plans

This is a bunch of ideas. Volunteers welcome!

Cross-compilation: The solver is now flexible enough to select components for multiple architectures at once. For example, it should be able to select source code and headers for a target platform, but choose versions of the build tools for the build platform.
Support for multiple ABIs (for C++ on Windows)
Alternatives for dependencies
App support for XDG launchers
HTTP connection pooling, pipelining and DNS caching: Rate limiting is already supported, but further performance improvements are still possible.
More flexible <recipe>s: e.g. applying patch files, unpacking nested archives
An app-store style interface: To help people get started quickly with 0install, it would be good to have a simple, familiar "app-store" user interface. Of course, without restricting people to just those applications.
Feed search: Add a free-text search engine for names and descriptions of locally cached feeds, to enable quick off-line searching.
Custom bug-report address: A feed should be able to specify where bug reports are to be sent. Currently, they all go to the 0install project itself.
Support for services: e.g. a 0service command that integrates with systemd. Juju support is currently under development.
Sandboxing: Provide better integration with sandboxing systems such as Rainbow, Plash or LXC. Sandboxed software must still be able to run other programs through Zero Install, adding them to the cache as needed in a secure fashion. EBox shows how this integration can work.
Better desktop integration: e.g. a better Firefox plugin, XFCE support.
wxWidgets GUI for Mac and Windows: Having a GUI that uses wxWidgets would make 0install much easier to use on Mac OS X and Windows, and would fit in better with the native look-and-feel.
Automatic cache cleaning: 0install can keep all versions of all libraries on disk at once. This is useful, but there should be a way to clean out ones that aren't needed any more to free up disk space. Individual versions can be removed easily enough via the cache explorer, but it should be more automatic, a bit like "apt-get autoclean" or deborphan. In particular, we need a way to remove a version which was shared between multiple users safely (i.e. only remove it once no user requires it).
Managing instances (configurations/profiles) of programs: 0install currently only manages code, not configuration. It is assumed that programs look in ~/.config and similar places for this. 0install should have support for multiple instances (configurations / profiles) for any program. This will be needed for sandboxing anyway.
Lazy dependencies: Support dependencies that are only downloaded when needed. For example, ROX-Filer's options box has a button to launch the MIME-Editor application. ROX-Filer should be able to depend on MIME-Editor in its feed, without requiring MIME-Editor to be downloaded before ROX-Filer can be started.
Plug-ins: It should be possible to add additional interfaces to a program's dependencies list. For example, you could add the interface for a French dictionary to a word processor to let you spell-check French documents. This would usually require some support from the application itself. A plug-in is a more general type of optional dependency; one which isn't listed in the main feed file at all.
More meta-data: Mailing list address, release notes, etc.
Peer-to-peer downloads: The tricky bit about P2P is normally the free-text searching, but we already know the secure hash of the manifest we want, and when we get it we have the hash of every file we need, so this should be easy! The idea is that if someone on your local network has already downloaded a program, you can get it from them automatically. See 0share for current experimental version.
Binary patches: We have the secure hash of the currently-cached versions, so we can check that they're unmodified. In that case, we could just download a delta to the next version rather than getting everything again. 0publish should create these deltas automatically. Rsync may also be an option for some sites.

Other possible features

Kiosk mode: The system administrator can restrict what software users can install using Zero Install (white-list interface URIs or trusted public keys).
Third-party sign-off: A distribution can sign an upstream release ("Certified for use with SUSE 10.2", etc). Users can set a policy to run only approved versions by default. Or, a third-party could provide additional input to the hints box (we already provide the "Unreliable hints database", but a commercial organisation could offer a real service).