========================================================================
Release Plans:
========================================================================


Items starting with "*" have been finished, while those marked with "-"
still need to be done.


nbb-0.1 (done)
 * Start new git repo (get rid of ndim-git-utils history).
 * Clean up git tags.


nbb-0.2
 * Make sure the "if cmp ... mv .. rm" in make rules are correct and useful,
   and the cmp is silent.
 * Make automake's "nbb make" depend on configure etc.
 * Switch to release tags including the package name


nbb-0.3
 - License review. Every source file needs a license. Trace back origin
   of all code.
 - Useful logging infrastructure, and --debug etc user interface.
 - Store config in ${srcdir}/.nbb.conf instead of 'git config'.
   More portable. bzr does not have a config interface, for example.


nbb-0.9 or earlier
 - Switch plugins.Foo.validate() functions to different protocol:
   Either return or raise an exception.
 - Use different exceptions for plugins signalling detection failure
   to detect() and detect() to signal "no matching plugin detected"
   to detect()'s caller.
 - BS support: cmake, scons, python setuptools ...
 - VCS support: SVN, darcs, hg, ...
 - Out-of-source builds for systems which require in-source-tree builds:
   "cp -rl foo.src foo.build"?
 - General removal of redundancy in Python code.
 - More declarative syntax elements in the Python code.
 - Use declarations for command line parsing, and help text generation.
   Use optparse stuff for both global params and extra optparse stuff
   for each command?
 - Add global --nick or similar option to determine the branch
   name to use for composing the pathes.
 - Model different "stages" of e.g. automake builds as distinct objects,
   including proper dependency detectors, and stuff? OK, we're not going
   to duplicate scons here.
 - Bash syntax completion, ideally autogenerated
 - Docs:
    - Write docs: README, NEWS, HACKING.
    - Man page or something similar. Generate from help texts?
 - Command aliases:
     make -> build    (for automake, or similar mapping)
 - Test sh command like run command.


nbb-1.0
 - Make public release.


========================================================================
DONE (some time in the past)
========================================================================

 * Separate generic plugin/command/etc. stuff and nbb specific
   code into separate modules.
 * Implement sh and run commands.
 * supports execution of user commands in source, build, install dirs
 * Do not move command objects to plugin detection framework (bad idea!)
 * Find or implement @abstractmethod decorator.
 * Unify detect() methods.
 * Design nice user interface. Requirements:
   * print top_srcdir, builddir, installdir. OK: 'config'
   * run 'autoreconf' type step. OK: 'init'
   * run 'configure' type step. OK: 'configure'
   * run 'make' type step. OK: 'build'
   * run 'make install' type step. OK: 'install'
   * run custom (make) commands. OK: 'make'
 * VCS config support ('git config', bzr does not support anything like that)
 * BS autodetection might discover more than one BS instance of the same type?
 * Test cases for proper handling of detecting (0, 1, >1) x (VCS, BS).
 * Build system support: automake/autoconf
 * Merge stuff from Eclipse to src/own/nbb and vice versa.
 * Write test cases for init, configure, build, install.
 * Write test cases for all nbb commands.
 * Determine required feature sets (properties, new-style classes, etc.)
   and then check that the Python environment is actually compatible.
   @classmethod -> Python 2.4
   new style classes -> Python 2.2
 * Add pydoc docs.
 * Fine-tune init, configure, build, install commands with knowledge
   gained with git-amb, especially the command interdependencies.
   (Nothing to do! :)


========================================================================
End of TODO file.
========================================================================