Reorganised roadmap, adding high-level goals

Signed-off-by: Ben Firshman <ben@firshman.co.uk>

ROADMAP.md

@@ -1,20 +1,28 @@
 # Roadmap
 
-## Fig 1.1
+Fig will be incorporated as part of the Docker ecosystem and renamed Docker Compose. The command-line tool and configuration file will get new names, and its documentation will be moved to [docs.docker.com](https://docs.docker.com).
 
-- All this cool stuff: https://github.com/docker/fig/issues?q=milestone%3A1.1.0+
+## More than just development environments
 
-## Compose 1.2
+Over time we will extend Fig's remit to cover test, staging and production environments. This is not a simple task, and will take many incremental improvements such as:
 
-- Project-wide rename and rebrand to Docker Compose, with new names for the command-line tool and configuration file
+- Fig’s brute-force “delete and recreate everything” approach is great for dev and testing, but it not sufficient for production environments. You should be able to define a "desired" state that Fig will intelligently converge to.
-- Version specifier in configuration file
+- It should be possible to partially modify the config file for different environments (dev/test/staging/prod), passing in e.g. custom ports or volume mount paths. ([#426](https://github.com/docker/fig/issues/426))
-- A “fig watch” command which automatically kicks off builds while editing code
+- Fig recommend a technique for zero-downtime deploys.
-- It should be possible to somehow define hostnames for containers which work from the host machine, e.g. “mywebcontainer.local”. This is needed by e.g. apps comprising multiple web services which generate links to one another (e.g. a frontend website and a separate admin webapp)
-- A way to share config between apps ([#318](https://github.com/docker/fig/issues/318))
 
-## Future
+## Integration with Swarm
 
-- Fig uses Docker container names to separate and identify containers in different apps and belonging to different services within apps; this should really be done in a less hacky and more performant way, by attaching metadata to containers and doing the filtering on the server side. **This requires changes to the Docker daemon.**
+Fig should integrate really well with Swarm so you can take an application you've developed on your laptop and run it on a Swarm cluster.
-- The config file should be parameterisable so that config can be partially modified for different environments (dev/test/staging/prod), passing in e.g. custom ports or volume mount paths. ([#426](https://github.com/docker/fig/issues/426))
+
-- Fig’s brute-force “delete and recreate everything” approach is great for dev and testing, and with manual command-line scoping can be made to work in production (e.g. “fig up -d web” will update *just* the web service), but a smarter solution is needed, its logic probably based around convergence from “current” to “desired” app state.
+## Applications spanning multiple teams
-- Compose should recommend a simple technique for zero-downtime deploys. This will likely involve new Docker networking methods that allow for a load balancer container to be dynamically hooked up to new app containers and disconnected from old ones.
+
+Fig works well for applications that are in a single repository and depend on services that are hosted on Docker Hub. If your application depends on another application within your organisation, Fig doesn't work as well.
+
+There are several ideas about how this could work, such as [including external files](https://github.com/docker/fig/issues/318).
+
+## An even better tool for development environments
+
+Fig is a great tool for development environments, but it could be even better. For example:
+
+- [Fig could watch your code and automatically kick off builds when something changes.](https://github.com/docker/fig/issues/184)
+- It should be possible to define hostnames for containers which work from the host machine, e.g. “mywebcontainer.local”. This is needed by apps comprising multiple web services which generate links to one another (e.g. a frontend website and a separate admin webapp)