Am 08.09.2016 um 00:26 schrieb Matthew Ahrens: > On Wed, Sep 7, 2016 at 12:05 PM, Joshua M. Clulow <[email protected]> wrote: >> On 7 September 2016 at 11:45, Gregor Kopka >> <[email protected]> wrote: >>> 1. Introduce two new option aliases that are functional identical to -r >>> and -R on the rollback command (named relating to their function, like >>> -c for child shapshots and -C for clones and bookmarks) and officially >>> deprecate use of -r and -R. >>> 2. After reasonable time has passed remove -r and -R from rollback so >>> unfixed scripts will fail and conversion to the new syntax is forced. >>> 3. Another reasonable time later, long enough that all legacy scripts >>> can be deemed to be updated, introduce -r to zfs rollback in the >>> 'operate recursively on the child datasets' form as it is used >>> everywhere else in zfs. >>> >>> It may take a while to phase out the current syntax but I think for the >>> long run it is the right way to go. >> There really is no "reasonable length of time" for phase 2 or 3 of >> this plan. The "zfs" and "zpool" commands are a committed, documented >> interface, which people are allowed (and encouraged!) to depend on. >> >> It's unfortunate when design decisions get made that turn out to be >> suboptimal in hindsight, but these are lessons to be observed when >> making future design decisions rather than opportunities to make >> breaking changes. > I agree with Josh, but we could do non-breaking changes to make this > less confusing, including > > 1. Add new, different options for the existing functionality (as > Gregor proposed) > 2. Print a warning of potential confusion when using the (deprecated, > but still functional) -r/-R options. > 3. Add new, different options for "recursive". > > The new options could even be --long-opts, e.g. --recursive or > --children, and we could use the same long opts for other commands > that operate recursively. That would at least be something, even if --long-opts are cumbersome and the confusion (being able to shorten it to -r everywhere except rollback) stays.
Nevertheless, I still don't see the need for later generations (zfs = futureproof) encountering the fallout of a bad decision of someone (possibly) long dead by then, and though I would like to see the change sooner than later the 'reasonable time' I though about was more towards years to give time to adapt to the change. So another take on the issue: Tying that option name change to a system tuneable (zfs.rollback-recursive-syntax) which can be used to walk through the steps of the proposal (as-is|deprecate-r|deprecate-r-and-warn|remove-r|r-is-really-recursive-now) with a sane default (as-is|deprecate-r|deprecate-r-and-warn). Then someone who read the changelog/documentation can opt to set the tuneable to live in a better future while someone who dosn't want it (for whatever reason) can set it to freeze the option naming to an eternal past and the curious can set it to test if a system will bomb somewhere. And should, some day, the decision be made to 'officially' cure this interface inconsistency it can be done by changing the default (without breaking scripts for people who read the documentation). ? Gregor ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
