Release 0.12.0 (#129)

* Update release version.

* Updates related to version 0.12.0.

RELEASE_BRANCH

@@ -1 +1 @@
-devnet_2024_05_07
+devnet_2024_09_04

RELEASE_VERSION

@@ -1 +1 @@
-0.11.3
+0.12.0

src/developers/advanced_topics/assets.md

@@ -28,12 +28,11 @@ does this:
         match operation {
             // ...
             Operation::CloseChain => {
-                for order_id in self.state.orders.indices().await? {
+                for order_id in self.state.orders.indices().await.unwrap() {
                     match self.modify_order(order_id, ModifyAmount::All).await {
-                        Ok(transfer) => self.send_to(transfer),
+                        Some(transfer) => self.send_to(transfer),
                         // Orders with amount zero may have been cleared in an earlier iteration.
-                        Err(MatchingEngineError::OrderNotPresent) => continue,
-                        Err(error) => return Err(error),
+                        None => continue,
                     }
                 }
                 self.runtime

src/developers/advanced_topics/oracles.md

@@ -10,6 +10,10 @@ The contract runtime currently has two oracle methods:
   service code. Services can access some off-chain information, so these are not
   guaranteed to return the same result each time they are called.
 - `http_post` makes an HTTP POST request and returns the response.
+- `assert_before` asserts that the block is being validated before a given time.
+
+The first two are disabled on public devnets and testnets for now, but can be
+used locally by compiling with the `unstable-oracles` flag.
 
 Applications should use these methods only in ways that make it very likely that
 all validators see the same result, otherwise any block proposals running that

src/developers/core_concepts/applications.md

@@ -93,7 +93,9 @@ can be sent from one chain to another, always within the same application. Block
 proposers also actively include messages in their block proposal, but unlike
 with operations, they are only allowed to include them in the right order
 (possibly skipping some), and only if they were actually created by another
-chain (or by a previous block of the same chain).
+chain (or by a previous block of the same chain). Messages that originate from
+the same transaction are included as a single transaction in the receiving
+block.
 
 In our "fungible token" application, a message to credit an account would look
 like this:

src/developers/core_concepts/overview.md

@@ -157,7 +157,7 @@ as follows.
 - [x] Permissioned chains (adding operation access control, demo of atomic
       swaps, etc)
 - [x] Avoid repeatedly loading chain states from storage
-- [ ] Blob storage usable by system and user applications
+- [x] Blob storage usable by system and user applications
       (generalizing/replacing bytecode storage)
 - [ ] Support for easy onboarding of user chains into a new application
       (removing the need to accept requests)

src/developers/getting_started/installation.md

@@ -4,7 +4,7 @@ Let's start with the installation of the Linera development tools.
 
 ## Overview
 
-The Linera toolchain consist of two crates:
+The Linera toolchain consists of two crates:
 
 - `linera-sdk` is the main library to program Linera applications in Rust.