Update version number, TODO.

[oweals/dinit.git] / TODO

diff --git a/TODO b/TODO
index 002f4a8e6547cc6ad7e544759759d111bce775cf..97babb0fd42b426bd5c8f1f6e65905ee0863cd6b 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,26 +1,21 @@
-For version 0.3.0:
+For version 0.5.0:
 ------------------
-* (Not yet decided).
-  
+* Man pages for all programs (done for dinit and dinitctl, not for shutdown/halt etc).
+* The DINIT_ROLLBACK_COMPLETED acknowledgement is never sent, since
+  control_conn_t::rollback_complete() is not currently called. Fix.
+* Write wtmp entry on startup (see simpleinit). Investigate.
+* Support S6-style startup notification (write to fd).
+
 For version 1.0:
 ----------------
-* Support S6-style startup notification (write to fd)
-* Man pages for all programs (done for dinit, not for dinitctl/shutdown/etc).
-* Write wtmp entry on startup (see simpleinit)
 * "triggered" service type: external process notifies Dinit when the service
   has started. (maybe?)
 * on shutdown, after repeated intervals with no activity, display information
   about services we are waiting on (or, do this when prompted via ^C or C-A-D).
-* A (perhaps limited) way(s) to modify a service description after it is loaded -
-  eg add/remove dependencies, change properties.
-* Think about detecting runs-on-console dependency conflicts (i.e. if A runs-on-console and
-  B depends on A and runs-on-consle then B can never start).
 * Documentation must be complete (see section below).
-* Package-manager-friendly way to enable/disable services.
-  Perhaps a service can specify a dependency file (with dependency type) where
-  the file contains a list of service names, or if it is a directory, each
-  filename within corresponds to a service that is a dependency.
+* Proper support for socket activation?
 * Be able to boot and shutdown Linux and FreeBSD.
+* Refuse to start new services during shutdown.
 
 For later:
 ----------
@@ -43,6 +38,13 @@ For later:
   But perhaps this really the responsibility of another daemon.
 * Allow running services with different resource limits, chroot, cgroups,
   namespaces (pid/fs/uid), etc
+* Support chaining service output to another process (logger) input; if the
+  service dies the file descriptor of its stdout isn't closed and is reassigned
+  when the service is restarted, so that minimal output is lost.
+  - even more, it would be nice if a single logger process could be responsible
+    for receiving output from multiple services. This would require some kind of
+    protocol for passing new output descriptors to the logger (for when a
+    service starts).
 
 Even later / Maybe never:
 -------------------------