On Fri, Dec 14, 2012 at 08:26:33PM -0800, Joe Mistachkin wrote: > > My opinion is that backward compatibility should be retained because various > people, including several that may not be involved in this discussion, have > existing scripts and other automation that relies upon the current behavior.
Backward compatibility should be broken sometimes. It is a decision that should be undertaken only with great care, but it should sometimes be undertaken. That's an important part of how software improves over time. > > Whether the current behavior being "ideal" or not is an entirely different > debate. > > My ideas on this issue are as follows: > > 1. Retain the existing behavior for all current commands and aliases. > It is far too dangerous to change the DEFAULT semantics of these > commands now. I disagree. A careful, measured approach to changing default behavior with a clear, unambiguous understanding of when and how things change mitigates the potential for problems. The major version number in semantic versioning practice, in fact, exists specifically for the purpose of indicating that backward compatbility has been broken. Thus, changes to default behavior that break backward compatibility should only be released in major version number releases (and their release candidates, if applicable), additions to the functionality of the software without destructive changes should only be released on major and minor version numbers, and fixes can be released on major, minor, or revision version numbers. This way, when you consider an upgrade, you know what you're getting into just by looking at the number. If you are not ready for changes in default behavior, don't upgrade to the next major version number. There is no good argument for software defaults to be set in stone for all time. Just use reasonable caution when releasing changes to default behavior. > > 2. Add entirely new commands named "relocate" (for mv) and "obliterate" > (for rm) that will perform actions on the repository itself as well as > the file system. Apart from the fact that these terms are already used elsewhere with distinctly different meanings (thus duplicating the problem that already exists), it does not solve the problem that already exists. > > 5. Optionally, add a -f/-filesystem option to the existing mv/rm > commands if there is consensus on this point. This new option will > cause the exact same behavior as the new commands, including the errors > as described above. Honestly, if the repurposing of the rm and mv commands is not to happen (though it should), this is the only suggestion that I think really makes sense for the project. A -f (--force, probably, rather than --filesystem) is better than `relocate` and `obliterate` commands as you have suggested, I think. Of course, the problem of surprising behavior for `rm` and `mv` would still apply in that case. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
