Tagging release 2.27.1

-----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCAAxFiEEtUHVUwEnDgvPFcpdgXC0cm1xmN4FAmfheacTHGVkb2xzdHJh
 QGdtYWlsLmNvbQAKCRCBcLRybXGY3kt2B/4tQvs6iDXA12d409ClHbVQjr1d0FLP
 rv8RxZ7Z4+Jaw8r2ra/I+gpr9juI5ULyEJWqfES72hTvbYPjH1Grsrrjak1tx57E
 +STs21oEPojE8LXsFH1oZamGPPIIpyQdxCvTgZs1N6cqUfCRQ3Jx97X6E6SIGJDR
 VqBM4ruSXCY57yT36HqwYydTkxzZHiNP5wwABGfSb7u9pYW5x3r8W7+fQ3udTnCw
 kCRhA5vnfxIQSlxu4j7dJqSCGzOIPnhYB19bXDV4aPhl4sn3pkBCdMZxPBlCWSwx
 it0ngMITf+TeiMpVl2TtvMBOHtlGrbhusbyKcsqzFYULGyGOC9ngTAY3
 =/JzB
 -----END PGP SIGNATURE-----

Merge tag '2.27.1' into detsys-main

Tagging release 2.27.1

doc/manual/source/protocols/derivation-aterm.md

@@ -1,6 +1,8 @@
 # Derivation "ATerm" file format
 
-For historical reasons, [derivations](@docroot@/glossary.md#gloss-store-derivation) are stored on-disk in [ATerm](https://homepages.cwi.nl/~daybuild/daily-books/technology/aterm-guide/aterm-guide.html) format.
+For historical reasons, [store derivations][store derivation] are stored on-disk in [ATerm](https://homepages.cwi.nl/~daybuild/daily-books/technology/aterm-guide/aterm-guide.html) format.
+
+## The ATerm format used
 
 Derivations are serialised in one of the following formats:
 
@@ -17,3 +19,20 @@ Derivations are serialised in one of the following formats:
   The only `version-string`s that are in use today are for [experimental features](@docroot@/development/experimental-features.md):
 
   - `"xp-dyn-drv"` for the [`dynamic-derivations`](@docroot@/development/experimental-features.md#xp-feature-dynamic-derivations) experimental feature.
+
+## Use for encoding to store object
+
+When derivation is encoded to a [store object] we make the following choices:
+
+- The store path name is the derivation name with `.drv` suffixed at the end
+
+  Indeed, the ATerm format above does *not* contain the name of the derivation, on the assumption that a store path will also be provided out-of-band.
+
+- The derivation is content-addressed using the ["Text" method] of content-addressing derivations
+
+Currently we always encode derivations to store object using the ATerm format (and the previous two choices),
+but we reserve the option to encode new sorts of derivations differently in the future.
+
+[store derivation]: @docroot@/glossary.md#gloss-store-derivation
+[store object]: @docroot@/glossary.md#gloss-store-object
+["Text" method]: @docroot@/store/store-object/content-address.md#method-text

doc/manual/source/protocols/json/derivation.md

@@ -32,6 +32,7 @@ is a JSON object with the following fields:
     For an output which will be [content addresed], the name of the hash algorithm used.
     Valid algorithm strings are:
 
+    - `blake3`
     - `md5`
     - `sha1`
     - `sha256`

doc/manual/source/protocols/json/store-object-info.md

@@ -35,10 +35,10 @@ In other words, the same store object residing in different store could have dif
 
 * `deriver`:
 
-  If known, the path to the [derivation] from which this store object was produced.
+  If known, the path to the [store derivation] from which this store object was produced.
   Otherwise `null`.
 
-  [derivation]: @docroot@/glossary.md#gloss-store-derivation
+  [store derivation]: @docroot@/glossary.md#gloss-store-derivation
 
 * `registrationTime` (optional):
 

doc/manual/source/protocols/store-path.md

@@ -53,7 +53,7 @@ where
     method of content addressing store objects,
     if the hash algorithm is [SHA-256].
     Just like in the "Text" case, we can have the store objects referenced by their paths.
-    Additionally, we can have an optional `:self` label to denote self reference.
+    Additionally, we can have an optional `:self` label to denote self-reference.
 
   - ```ebnf
     | "output:" id