monotone implementation road map

Release 1.0 - Early 2011

Description	More Info	Branch(es)	Status
Cleanup the source tree	n/a	net.venge.monotone.source-tree-cleanup	done, merged
Sanitize i18n strings (quotation, phrases, ...)	monotone-devel	net.venge.monotone.string-sanitization	done, merged
Finalize maintained translations	n/a	n/a	started
Fix open issues in the tracker	code forge	n/a	started
Update INSTALL_windows_native.txt to newer MinGW versions	n/a	net.venge.monotone.mingw-instructions	started
Cleanup and document stuff in contrib/	monotone-devel	n/a	started

Release 1.x - 2011

Description	More Info	Branch(es)	Status
rename --guess	n/a	nvm.rename-guess	somewhat abandoned
Clean workspace from unknown / ignored files	n/a	nvm.tkoskine.purge	in development
netsync --anonymous	n/a	nvm.bugfest-2010.28805-rlevitte	in development
Colored diff and log output	n/a	nvm.colored-diff	in development

Release 2.0 - Late 2011

Description	More Info	Branch(es)	Status
Remove netsync's SERVER [PATTERN] syntax	n/a	n/a	not started

Not targeted

Description	More Info	Branch(es)	Status	Major Version Change
Sane SQLite locking	monotone-devel	n/a	not started	No
Policy Branches	VersionedPolicy	nvm.tbrownaw.policy-branches, nvm.experimental.policy-branches*	in development	Yes
Daggy refinement	DagBasedRefinement	n/a	not started	No - netsync version negotiation
SSL for netsync	n/a	n/a	not started	No - netsync version negotiation
Partial pull	PartialPull	n/a	not started	No - netsync version negotiation
Let die-die-die die	n/a	n/a	not started	Yes - revision format change
'mountpoint' node type	n/a	n/a	not started	Yes - revision format change
Command naming cleanup	n/a	n/a	not started	Probably - if sufficiently extensive, or it touches the automate commands
Netsync preview	n/a	n/a	not started	No - I don't think this would need any on-the-wire changes at all
Update conflict handling	UpdateConflicts	n/a	not started	No
Allow - and _ interchangeably in commands and options	n/a	n/a	not started	No
"Packed" revisions	monotone-devel	n/a	not started	Probably not

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.