[tahoe-dev] on backward-compatibility and new features
Zooko Wilcox-O'Hearn
zooko at zooko.com
Wed Nov 18 10:26:48 PST 2009
Folks:
This is a general lesson that I've learned over the years, from
following the darcs project among other things.
Consider this use case:
There is a person who uses Tahoe-LAFS vX, and she shares files with
other people who use Tahoe-LAFS vX, such as friends, family, or
members of her organization or company. She wants to upgrade her
Tahoe-LAFS to vX+1 even though the people that she shares with aren't
ready to upgrade theirs. *And* she doesn't want to change anything
about her work-flow or configuration, nor does she want to read the
NEWS file carefully and think about compatibility issues.
This implies that any new backwards-incompatible feature that is
added in Tahoe-LAFS vX+1, such as immutable directories, has to be
disabled by default, and to be turned on only by explicit action on
the part of the user.
So concretely, we should make sure that in Tahoe-LAFS v1.6
directories are created mutable by default, just like in Tahoe-LAFS
v1.5. This is easy because the way that directories were created in
Tahoe-LAFS v1.5 was to create a new empty mutable directory, and
there is no point in creating a new empty immutable directory. :-)
It would probably be wise to make the "tahoe backup" command continue
to create mutable directories by default, because there might be
people who use "tahoe backup" to create directories which they then
share with their friends. I know that immutable directories in
"tahoe backup" are sweet (#606), and I want people to use them, but
for Tahoe-LAFS v1.6 the way to get people to use them should be to
announce them in the NEWS and explain them in the docs and tell
people to turn them on in their configuration.
Anyway, part of my reason to post this is to inform developers and to
reassure users that the use case sketched above is important to me.
If this use case isn't taken care of, then what happens is people
just put off upgrading until all of the people they share with have
upgraded, which can sometimes mean forever.
I would like people to get used to the idea that they can always
upgrade to the new version of Tahoe-LAFS and continue sharing with
their more conservative friends without having to even think about
these issues.
This is also why "forward-compatibility" features are so important to
me. They can sometimes ease these transitions. Here is the list of
tickets tagged "forward-compatibility":
http://allmydata.org/trac/tahoe/query?status=%21closed&keywords=%
7Eforward-compatibility
Regards,
Zooko
http://allmydata.org/trac/tahoe/ticket/606# backupdb: add directory
cache
More information about the tahoe-dev
mailing list