monotone implementation road map

Release 1.0 - Early 2011

Release 1.x - 2011

Release 2.0 - Late 2011

Not targeted

Version numbering scheme

We, the monotone developers, release new versions of monotone on a regular basis. Starting with 1.0 we introduce a new version numbering scheme, which distinguishes between four all-numeric parts: the major version number, the minor version number, the patch version number and the development version number (the last is required to be >= 90).

A valid version must now consist of at least two parts, of which the major version number is always the first and a minor or development version follows, and might consist of up to four parts. This leads to the following list of valid monotone versions: <major>.<devel>, <major>.<minor>, <major>.<minor>.<devel>, <major>.<minor>.<patch> and <major>.<minor>.<patch>.<devel>.

What follows now is the contract we offer you with respect to the aforementioned versions we release:

• For patch releases: We are only allowed to make bug fixes, i18n and / or documentation updates.
• For minor releases: All of the above, plus we are allowed to make backwards compatible feature enhancements, do local database migrations and / or feature deprecations.
• For major releases: All of the above, plus we are allowed to break netsync, make backwards-incompatible changes in the automate interface, remove previously deprecated features, and / or do general system redesigns.
• For devel releases: We are allowed to do whatever changes we are allowed to do for the actual release we target with the particular development release.

We are planning to support major and minor releases with patch releases as long as they're needed and useful for the community, i.e. as long there is a demand for them. Major version support will have our precendence over minor version support though.

Finally here are some example version numbers and what they mean to us:

• 1.0 - the first major release
• 1.3 - the third minor release of the first major release
• 1.2.4 - the fourth patch release of the second minor release of the first major release
• 1.90, 1.2.90, 1.2.3.90 - an unmarked development release of an upcoming major (2.0), minor (1.3) and patch (1.2.4) release
• 1.91, 1.92, 1.93, ... - the first, second, third ... beta release / release candidate of an upcoming major (2.0) release (we do not plan to release betas or RCs for minor and patch releases)

Uncategorized ideas / TODO from the old ROADMAP file

General

• tidy up major build/use-breaking bugs in win32, BSD, OSX versions
  • fix codepage-/non-utf8-related problems
• improve netsync error reporting code
  • one part: many 'I's should be 'require's.
• move output formatting to lua hooks
• implement improved ACL/permission system for default trust rules
• continue the implementation of "merge into workspace"
• work on GUIs and web UIs
• maybe "merge before commit" (CVS-style online commit-coordination)
• bidirectional mirroring between monotone and CVS/SVN/arch/git - we need a git importer!
• "hash-migration" technology for scenarios where SHA1 falls
• ease long-term maintainance by writing up a real hacking guide (.texi, based on expanded HACKING file, a guided tour of code, and a thorough description of the more complicated algorithms) for new maintainers.

There are also some issues which are very regular, mundane, tedious, boring, but ultimately pretty mechanical. They need doing too:

Janitorial

• librarification: several discrete steps, each mechanical, best to do a compile and commit after each.

  • make a struct for each file.
  • make every "plain" function in the file a static member of the struct
  • make every global/static object in the file a static member of the struct
  • make every reference to an out-of-file global/static happen via a static reference stored inside the struct, initialized at load time
  • remove static-ness of references, from file to file, until there is a single root value for the whole application

  (nb: this is not to say that monotone will every be packaged or provided as a library, simply that it's a little more flexible, and easier to see dependencies between modules, when you have things structured this way. we should have been doing so all along, but we were lazy)

• possibly purge the whole packet-reading/writing stuff.
• implement a pager so that long outputs get automatically paged if the terminal is intelligent enough to support this feature. cogito does this and it is very convenient. (how many times have you had to rerun a command just to pipe it to more(1) or less(1)?)
• abstract the way arguments are checked when running a command. given that each command has a "params" member that describes its syntax, it seems fairly easy to homogenize its syntax, write a simple syntax parser for it and use it to sanity-check the command line given by the user. this could remove a lot of inconsistencies in error messages that exist in the current code because, at the moment, each command is reponsible of checking the 'args' size and format to report errors.
• remove the special-casing of top-level commands. ideally they should behave just like any other command that accepts subcommands (e.g. 'list'). however, the command lookup routine has to support ignoring the top-level command if not given to preserve compatibility and not complicate things a lot. e.g. 'mtn informative list' should be the same as 'mtn list'.
• modify the CMD_AUTOMATE macro so that it can document all the details of an automate command (input, output, first version, etc.). the idea is to move all the documentation for automate commands (currently placed in comments in the code) to the online help system.