Rsync "roadmap" and version numbering (3.1.0 vs 3.0.4)

[Wayne Davison]

I think it's about time to start adding some new features to rsync 3
instead of just making bug fixes, so I'm planning to starting work on
version 3.1.0.  This will start the use of a new version numbering
idiom where feature releases increment the sub-version number, while
patch releases continue to increment the sub-sub-version number.  I'm
not using an odd/even scheme for beta/stable releases, but separating
feature-oriented releases will make it easy to continue to release
bug-fixes and/or security fixes for an earlier rsync for those that
may not want to start in on the latest feature release.

So, I'm still hoping that the folks who have been experiencing problems
with the hard-link and xattr code will be able to help me get some fixes
made to 3.0.3, at which point I can release a version 3.0.4.

As for 3.1.0, one of the new features that I'm considering is a new
patch that adds a feature that JW Schultz was advocating several years
back:  an ability to specify finer-grained output control for report
(informational) and debug messages.  I'd be interested in reactions
to the following patch that adds the --report=FLAGS and --debug=FLAGS
options (and leaves --verbose the same as it ever was from a user
perspective):

    http://rsync.samba.org/ftp/rsync/dev/patches/report_debug.diff

If that goes in, it will be easy to add more info/debug messages to
parts of the code that might need to be fleshed out more (and then
debugging something like the xattr code won't require you to wade
through a ton of checksum debug messages too).

I'd also like reactions to the --remote-option patch, which is also
on my list of early additions:

    http://rsync.samba.org/ftp/rsync/dev/patches/remote-option.diff

Other things in the patches dir, suggestions made here, and enhancement
requests from bugzilla will all be reviewed for possible inclusion.

Thoughts?

..wayne..