publish new versions (#3591)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

.changes/http-redirect-scope.md

@@ -1,19 +0,0 @@
----
-"http": minor
----
-
-**Security:** Added the `scopeRedirects` plugin configuration option, which checks the URL scope on every hop of a redirect chain instead of only on the URL requested by the frontend. Without it, a server on an allowed origin can redirect the request to any other origin - including `localhost` services, internal hosts and cloud metadata endpoints - and the plugin follows it, returning the response to the webview.
-
-```json
-{
-  "plugins": {
-    "http": {
-      "scopeRedirects": true
-    }
-  }
-}
-```
-
-It is opt-in because a redirect to a URL that is not allowed by the scope now fails with `url not allowed on the configured scope` instead of being followed, so applications that rely on being redirected outside of their scope must add the redirect target to the scope. **This will become the default in v3.**
-
-Note that `tauri_plugin_http::init()` now returns `TauriPlugin<R, Option<Config>>` instead of `TauriPlugin<R>`.

.changes/log-webview-double-colon.md

@@ -1,6 +0,0 @@
----
-"log": patch
-"log-js": patch
----
-
-Log webview log target locations after 2 colons instead of 1. (e.g. `webview:myFunction@http://localhost:5173/src/myFile.ts?t=1787480723620:47:4` to `webview::myFunction@http://localhost:5173/src/myFile.ts?t=1787480723620:47:4`)

.changes/single-instance-foreground-rights.md

@@ -1,5 +0,0 @@
----
-"single-instance": patch
----
-
-On Windows, the second instance now allows the first instance to bring its window to the front before exiting, so focusing a window from the callback no longer gets refused by Windows.

.changes/updater-allow-downgrades-config.md

@@ -1,20 +0,0 @@
----
-"updater": minor
-"updater-js": minor
----
-
-**Breaking change:** the `allowDowngrades` option was removed from the `check` command and is now read from the plugin configuration instead.
-
-Previously any code running in the webview could pass `allowDowngrades: true` to `plugin:updater|check` and relax the version check from "the update must be newer" to "the update must be different", overriding the comparator the application had configured on the Rust side. The flag is now an application-level setting:
-
-```json
-{
-  "plugins": {
-    "updater": {
-      "allowDowngrades": true
-    }
-  }
-}
-```
-
-It defaults to `false`, and is ignored when the application provides its own `Builder::default_version_comparator`, which continues to take precedence.

.changes/updater-require-signed-version.md

@@ -1,23 +0,0 @@
----
-"updater": minor
----
-
-Add a `requireSignedVersion` configuration option that binds an update to the version it was signed for.
-
-The update endpoint response is fetched over TLS but is not itself signed, and the signature only covers the downloaded artifact. Anyone able to serve a crafted response could therefore pair an inflated `version` field with the `url` and `signature` of an older release and force a downgrade to a genuine but outdated build, because that older artifact carries a valid signature.
-
-The Tauri CLI records the version in the signature's trusted comment, which the signature covers. With this option enabled the updater compares that signed version against the one announced by the endpoint and rejects the update when they differ:
-
-```json
-{
-  "plugins": {
-    "updater": {
-      "requireSignedVersion": true
-    }
-  }
-}
-```
-
-It defaults to `false` because releases signed before the CLI started recording the version carry none and would be rejected. Re-sign and re-publish every release your users can still update from before enabling it, otherwise an older signature can still be served to bypass the check. When the signature does carry a version, a mismatch is rejected whether or not the option is enabled.
-
-This is checked independently of `allowDowngrades`: it constrains which artifact a given version number may resolve to, not whether that version is newer than the running one.