Merge pull request #131 from nginx/1.32.1

Add Release-Notes for 1.32.1

Author: JTorreG

source/conf.py

@@ -5,8 +5,8 @@
 project = 'NGINX Unit'
 author = 'NGINX, Inc.'
 copyright = '2017-2024'
-version = '1.32.0'
-release_date = 'Feb 27, 2024'
+version = '1.32.1'
+release_date = 'Mar 26, 2024'
 release = version
 needs_sphinx = '6.2'
 

source/configuration.rst

@@ -5025,31 +5025,21 @@ you have:
 .. list-table::
    :header-rows: 1
 
-    * - Option
-      - Description
-
-    * - **script** (required)
-      - String;
-         rack script pathname,
-         including the **.ru** extension,
-         for instance:
-         **/www/rubyapp/script.ru**.
+   * - Option
+     - Description
 
-    * - **hooks**
-      - String;
-         pathname of the **.rb** file
-         setting the event hooks
-         invoked during the app's lifecycle.
+   * - **script** (required)
+     - String; rack script pathname, including the **.ru** extension,
+       for instance: **/www/rubyapp/script.ru**.
 
-    * - **threads**
-      - Integer;
-         number of worker threads
-         per :ref:`app process <sec-processes>`.
-         When started,
-         each app process creates this number of threads
-         to handle requests.
+   * - **hooks**
+     - String; pathname of the **.rb** file setting the event hooks invoked
+       during the app's lifecycle.
 
-         The default is **1**.
+   * - **threads**
+     - Integer; number of worker threads per
+       :ref:`app process <sec-processes>`. When started, each app process
+       creates this number of threads to handle requests. The default is **1**.
 
 Example:
 

source/news/2024/index.rst

@@ -4,6 +4,14 @@ News of 2024
 
 News archive for the year 2024.
 
+.. nxt_news_entry::
+   :author: Unit Team
+   :description: Version 1.32.1 is a maintenance release that fixes bugs in the new WebAssembly Language Module and in our NJS implementation.
+   :email: [email protected]
+   :title: Unit 1.32.1 Released
+   :url: news/2024/unit-1.32.1-released
+   :date: 2024-03-26
+
 .. nxt_news_entry::
    :author: Timo Stark
    :description: Building Wasm Components using Fermyon's Spin SDK for Rust

source/news/2024/unit-1.32.1-released.rst

@@ -0,0 +1,52 @@
+:orphan:
+
+####################
+Unit 1.32.1 Released
+####################
+
+NGINX Unit 1.32.1 is a maintenance release that fixes bugs in the new WebAssembly Language Module and in our NJS implementation.
+
+===============
+Resolved issues
+===============
+
+This release fixes the following issues:
+
+**************************************************************
+Applications of type `wasm-wasi-component` can't be restarted
+**************************************************************
+
+Applications deployed as `wasm-wasi-components` can't be restarted using the `restart` endpoint.
+
+After deploying a new Wasm Component binary to disk, the restart will trigger a reload of the component in Unit without restarting the server.
+
+As restarts will work independently of the application type, the behavior shipped with **1.32.0** was not right. It has been fixed in this release.
+
+
+************************************************************
+Unit-variables in NGINX JavaScript are constantly cached
+************************************************************
+
+In **1.32.0** we added the possibility to access all Unit variables form inside NJS.
+
+As reported in GitHub issue `#1169 <https://github.com/nginx/unit/issues/1169>`__ the variables were cached and would hold the wrong value, which is not how this feature should work. With version 1.32.1, we have fixed this issue.
+
+
+==============
+Full Changelog
+==============
+
+.. code-block:: none
+
+    Changes with Unit 1.32.1                                         26 Mar 2024
+
+        *) Bugfix: NJS variables in templates may have incorrect values due to
+           improper caching.
+
+        *) Bugfix: Wasm application process hangs after receiving restart signal
+           from the control.
+
+
+
+For a full list of changes and bugfixes,
+please see the `changelog <../../../CHANGES.txt>`__.

source/news/2024/wasm-component-model-part-2.rst

@@ -19,7 +19,7 @@ This tutorial targets Linux-based operating systems and MacOS. If you are on Win
 Rust Development Setup
 =============================
 
-Let's start by installing the Rust ecosystem, if not already done. At the time of writing, Rust 1.76 is the latest stable version. 
+Let's start by installing the Rust ecosystem, if not already done. At the time of writing, Rust 1.76 is the latest stable version.
 To install Rust, see the instructions on their `website <https://www.rust-lang.org/tools/install>`__.
 
 After the installation completes, you can confirm the current version of Rust by running:
@@ -45,7 +45,7 @@ The wasm32-wasi compiler target will provide general Wasm support to your rustc
 Install cargo-component
 ======================================
 
-**cargo-component** will add a cargo subcommand to build Wasm Components without any intermediate steps from our Rust project. 
+**cargo-component** will add a cargo subcommand to build Wasm Components without any intermediate steps from our Rust project.
 To install the latest version, run the following command:
 
 .. code-block:: bash
@@ -56,7 +56,7 @@ To install the latest version, run the following command:
 Install wasmtime runtime and CLI for testing
 =================================================
 
-The wasmtime-cli will be used to test and play around with the Wasm component. At the time of writing, we are using Wasmtime 18. 
+The wasmtime-cli will be used to test and play around with the Wasm component. At the time of writing, we are using Wasmtime 18.
 To install the latest version of Wasmtime, run:
 
 .. code-block:: bash
@@ -68,6 +68,7 @@ For more information about Wasmtime and installing it, see their `GitHub reposit
 Once we have all the tools in place, we can create the Rust projects.
 
 .. _tutorial-rust-based-wasm-component:
+
 ======================================
 Using the **wasi** Rust library
 ======================================
@@ -152,7 +153,7 @@ Targeting the wasi crate requires some low-level Rust work by us. Not bad at all
 Let's build the component. Run the following command from the **test-wasi-component** directory:
 
 .. code-block:: bash
-   
+
    $ cargo component build --release
 
 The build shows a very small dependency footprint, so is a major benefit from the wasi crate.
@@ -194,7 +195,7 @@ Sending a request to the exposed endpoint will output something like this:
 NGINX Unit for production grade Wasm workloads
 ************************************************************************
 
-While the **wasmtime-cli**  interface is good for testing Wasm components locally, there are more requirements for production workloads. 
+While the **wasmtime-cli**  interface is good for testing Wasm components locally, there are more requirements for production workloads.
 
 With NGINX Units Wasm runtime, you will be able to run your Wasm workloads next to other host applications on a single host and make use of all the other powerful Unit features. Given Units design and as we have decoupled the listeners from the application runtime, you can make full use of the Unit Router to make routing decisions before sharing a request with your Wasm Component or add HTTPS to your stack.
 
@@ -216,7 +217,7 @@ Create a **config.json** file:
             "component": "path/target/wasm32-wasi/release/test_wasi_component.wasm"
          }
       }
-   }   
+   }
 
 Apply the configuration using **unitc**: