Leasedb and cloud backend merge is scheduled for v1.12.0.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

diff --git a/docs/backends/disk.rst b/docs/backends/disk.rst
index c4e54c67e17081d0356a6912fb3e9efcabb57226..eaed40a1ca8d826ebc0dd9d0f2c6bf1076864de2 100644 (file)
--- a/docs/backends/disk.rst
+++ b/docs/backends/disk.rst
@@ -3,7 +3,7 @@ Storing Shares on a Local Filesystem
 ====================================
 
 The "disk" backend stores shares on the local filesystem. Versions of
-Tahoe-LAFS before v1.11.0 always stored shares in this way.
+Tahoe-LAFS before v1.12.0 always stored shares in this way.
 
 ``[storage]``
 

diff --git a/docs/garbage-collection.rst b/docs/garbage-collection.rst
index 2078fdcc35b48657f880c74cf6056835815e2051..091f13eb32a087129ad77c8be9c0ecb7133ad9c2 100644 (file)
--- a/docs/garbage-collection.rst
+++ b/docs/garbage-collection.rst
@@ -205,13 +205,13 @@ The ``tahoe.cfg`` file uses the following keys to control lease expiration:
 
 In previous versions, the ``expire.immutable`` and ``expire.mutable`` keys
 could be used to selectively expire only mutable or only immutable shares.
-As of Tahoe-LAFS v1.11.0, these are no longer supported and will cause an
+As of Tahoe-LAFS v1.12.0, these are no longer supported and will cause an
 error if set to ``False``.
 
 Expiration Progress
 ===================
 
-As of Tahoe-LAFS v1.11.0, leases are stored in a database that can be queried
+As of Tahoe-LAFS v1.12.0, leases are stored in a database that can be queried
 and updated quickly, rather than in share files. However, an "accounting
 crawler" is still needed to discover shares when upgrading from a previous
 version, and to actually delete expired shares. The crawler limits the amount

diff --git a/docs/proposed/leasedb.rst b/docs/proposed/leasedb.rst
index cab0e103ccf935abd0db3140f5ba88b0e36468ea..21f81c7bba1628d90825ee8d5078758583f059f0 100644 (file)
--- a/docs/proposed/leasedb.rst
+++ b/docs/proposed/leasedb.rst
@@ -5,7 +5,7 @@ Lease database design
 =====================
 
 The target audience for this document is developers who wish to understand
-the new lease database (leasedb) planned to be added in Tahoe-LAFS v1.11.0.
+the new lease database (leasedb) planned to be added in Tahoe-LAFS v1.12.0.
 
 
 Introduction

diff --git a/src/allmydata/interfaces.py b/src/allmydata/interfaces.py
index ce34662f9301be0be50d8115d94b78ec7cae7fe2..35d9f8e6773d62ecb58482e507e932190b766306 100644 (file)
--- a/src/allmydata/interfaces.py
+++ b/src/allmydata/interfaces.py
@@ -101,7 +101,7 @@ class RIStorageServer(RemoteInterface):
         """
         Allocate BucketWriters for a set of shares on this server.
 
-        renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.11.0,
+        renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.12.0,
         but for backward compatibility with older servers, should be
         calculated in the same way as previous clients (see
         allmydata.util.hashutil.file_{renewal,cancel}_secret_hash).
@@ -139,7 +139,7 @@ class RIStorageServer(RemoteInterface):
         longer lease), but expiration behaviour also depends on the server's
         configured policy (see docs/garbage-collection.rst).
 
-        renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.11.0,
+        renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.12.0,
         but for backward compatibility with older servers, should be
         calculated in the same way as previous clients (see
         allmydata.util.hashutil.file_{renewal,cancel}_secret_hash).
@@ -156,14 +156,14 @@ class RIStorageServer(RemoteInterface):
         longer lease), but expiration behaviour also depends on the server's
         configured policy (see docs/garbage-collection.rst).
 
-        renew_secret is ignored as of Tahoe-LAFS v1.11.0, but for backward
+        renew_secret is ignored as of Tahoe-LAFS v1.12.0, but for backward
         compatibility with older servers, should be calculated in the same
         way as previous clients (see
         allmydata.util.hashutil.file_renewal_secret_hash). In versions
-        prior to v1.X.0, this method would only renew leases with the given
+        prior to v1.12.0, this method would only renew leases with the given
         renew_secret.
 
-        Note that as of Tahoe-LAFS v1.11.0, the lease database does not retain
+        Note that as of Tahoe-LAFS v1.12.0, the lease database does not retain
         information about the node ids of lease holders, so if an IndexError
         is raised for a mutable share, it no longer includes that information.
         """
@@ -212,7 +212,7 @@ class RIStorageServer(RemoteInterface):
 
         The 'secrets' argument is a tuple of (write_enabler, renew_secret,
         cancel_secret). The first is required to perform any write.
-        renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.11.0,
+        renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.12.0,
         but for backward compatibility with older servers, should be
         calculated in the same way as previous clients (see
         allmydata.util.hashutil.file_{renewal,cancel}_secret_hash).

diff --git a/src/allmydata/storage/backends/disk/immutable.py b/src/allmydata/storage/backends/disk/immutable.py
index 0363b8fe2d156544095b654198fb3780595e71a8..61da7d93ca80cbd95eccf6fd93eef9d88b823fe6 100644 (file)
--- a/src/allmydata/storage/backends/disk/immutable.py
+++ b/src/allmydata/storage/backends/disk/immutable.py
@@ -24,7 +24,7 @@ from allmydata.storage.common import si_b2a, CorruptStoredShareError, UnknownImm
 
 # Footnote 1: as of Tahoe v1.3.0 this field is not used by storage servers.
 
-# Footnote 2: as of Tahoe v1.11.0 this field is not used by storage servers.
+# Footnote 2: as of Tahoe v1.12.0 this field is not used by storage servers.
 # New shares will have a 0 here. Old shares will have whatever value was left
 # over when the server was upgraded. All lease information is now kept in the
 # leasedb.