fix: list indentation

CHANGELOG.md

@@ -1,12 +1,3 @@
-# Continuwuity 26.6.2 (2026-07-12)
-
-## Bugfixes
-
-- Fixed the server returning 500 errors if `admin_console_automatic` is enabled and no TTY is available. Contributed by @s1lv3r. (#1975)
-- Fixed `global.oauth.compatibility_mode` being required, despite being ignored, when the `[global.oauth.oidc]` config section is provided.
-- Fixed an issue with a migration that could cause user accounts imported from an identity provider to be marked as deactivated when the server started. If you have accounts affected by this issue, use `!admin users reset-password --convert-to-local-account` to reactivate them.
-
-
 # Continuwuity 26.6.1 (2026-07-12)
 
 ## Features

Cargo.lock

@@ -826,7 +826,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "aws-lc-rs",
  "clap",
@@ -864,7 +864,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_admin"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "assign",
  "clap",
@@ -890,7 +890,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_api"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "assign",
  "async-trait",
@@ -928,7 +928,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_build_metadata"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "built",
  "cargo_metadata",
@@ -936,7 +936,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_core"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "argon2",
  "arrayvec",
@@ -1004,7 +1004,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_database"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "async-channel",
  "conduwuit_core",
@@ -1025,7 +1025,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_macros"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "cargo_toml",
  "itertools 0.15.0",
@@ -1036,7 +1036,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_router"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "assign",
  "axum",
@@ -1074,7 +1074,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_service"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "askama",
  "assign",
@@ -1126,7 +1126,7 @@ dependencies = [
 
 [[package]]
 name = "conduwuit_web"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "askama",
  "assign",
@@ -4799,7 +4799,7 @@ dependencies = [
 
 [[package]]
 name = "ruminuwuity"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "assign",
  "ruma",
@@ -6972,7 +6972,7 @@ dependencies = [
 
 [[package]]
 name = "xtask"
-version = "26.6.2"
+version = "26.6.1"
 dependencies = [
  "askama",
  "cargo_metadata",

Cargo.toml

@@ -12,7 +12,7 @@ license = "Apache-2.0"
 # See also `rust-toolchain.toml`
 readme = "README.md"
 repository = "https://forgejo.ellis.link/continuwuation/continuwuity"
-version = "26.6.2"
+version = "26.6.1"
 
 [workspace.metadata.crane]
 name = "conduwuit"

changelog.d/+6d0bc844.bugfix.md

@@ -0,0 +1 @@
+Fixed `global.oauth.compatibility_mode` being required, despite being ignored, when the `[global.oauth.oidc]` config section is provided.

docs/development/_meta.json

@@ -1,27 +1,32 @@
 [
-    {
-        "type": "file",
-        "name": "index",
-        "label": "Development Guide"
-    },
-    {
-        "type": "file",
-        "name": "contributing",
-        "label": "Contributing"
-    },
-    {
-        "type": "file",
-        "name": "code_style",
-        "label": "Code Style Guide"
-    },
-    {
-        "type": "file",
-        "name": "testing",
-        "label": "Testing"
-    },
-    {
-        "type": "file",
-        "name": "hot_reload",
-        "label": "Hot Reloading"
-    }
+  {
+    "type": "file",
+    "name": "index",
+    "label": "Development Guide"
+  },
+  {
+    "type": "file",
+    "name": "contributing",
+    "label": "Contributing"
+  },
+  {
+    "type": "file",
+    "name": "code_style",
+    "label": "Code Style Guide"
+  },
+  {
+    "type": "file",
+    "name": "testing",
+    "label": "Testing"
+  },
+  {
+    "type": "file",
+    "name": "hot_reload",
+    "label": "Hot Reloading"
+  },
+  {
+    "type": "file",
+    "name": "releasing",
+    "label": "Releasing"
+  }
 ]

docs/development/releasing.mdx

@@ -0,0 +1,77 @@
+# Releasing
+
+Continuwuity is rapidly evolving software that needs to keep up with an ecosystem that demands equally faced paced
+development. While we generally encourage people follow the `main` branch, not everyone has the time or will to keep up
+with even nightly updates. For this reason, we do regular releases.
+
+In order to ensure that releases are stable and predictable, the process defined in this document should be followed.
+
+## Schedule
+
+The release `YY.MM` should be forked from the `main` branch on the first day of the final week of the month.
+Immediately after, `YY.MM.0-rc.1` should be tagged and released as a pre-release.
+
+Then, for each day of the final week of the month, if there have been bug fixes since the last release candidate, a new
+release candidate should be tagged and released as a pre-release. This means there can be between 1 and 6
+release candidates for a given release.
+
+On the last day of the final week of the month, if there are no outstanding serious bugs, the full release should be
+tagged and released.
+
+If there ARE serious bugs found at the time the final release is due, the release should be delayed until the
+bugs are fixed. Additionally, another release candidate should be tagged for at least 24 hours after the patch is
+released, to allow for testing and verification of the fix. Only then can the final release be made.
+
+This means a release timeline MIGHT look like:
+
+- Week 1: Bugfixes from the previous release that missed the cycle
+- Week 2: New major features & other changes
+- Week 3: New minor features & bugfixing
+- Week 4: Release candidates and final release
+  - Day 1: Fork release branch from `main` and tag `YY.MM.0-rc.1`
+  - Day 2: If there are bugfixes, tag `YY.MM.0-rc.2`
+  - Day 3: If there are bugfixes, tag `YY.MM.0-rc.3`
+  - Day 4: If there are bugfixes, tag `YY.MM.0-rc.4`
+  - Day 5: If there are bugfixes, tag `YY.MM.0-rc.5`
+  - Day 6: If there are bugfixes, tag `YY.MM.0-rc.6`
+  - Day 7: If there are no serious bugs, tag `YY.MM.0` and release.
+
+New changes of any sort may be made to the `main` branch at any point during the month, but they will not be included
+in the release until the next cycle.
+
+### Off-schedule releases (patches)
+
+Sometimes, critical bugs may be discovered that require an immediate release.
+In this case, a new branch should be forked **from the previous release tag**, incrementing the patch value (e.g. `YY.MM.0` ->` YY.MM.1`)
+This will ensure that the critical bug is fixed without introducing any new changes that may potentially be incompatible.
+
+### Security releases
+
+Following the [security policy](../security.mdx), security releases might be made off-cycle, and may even require
+creating new releases for older versions (backports). It is imperative that security patches are tested BEFORE being
+pushed to the public repository, as once the cat is out of the bag, it doesn't go back in. Consequently,
+there is no "pre-release" system for security releases - security patches always go straight to release.
+
+Not all security fixes require a new release. If there are several low-severity security problems that are awaiting
+an upstream merge, they should instead wait for the next scheduled release, unless they are critical enough to warrant
+an immediate release.
+
+Security patches should NEVER be pushed to the public repository when a release is not planned to be made very soon
+after. The shorter the window between the diff going live and the release, the smaller the window for exploit.
+
+### Release candidates
+
+Release candidates are the primary form of pre-release - they imply a feature freeze, which allows maintainers and
+contributors to focus on fixing bugs before the ultimate release, which ensures all new features are stable and working
+as intended. Simply relying on deployments to run main has proven to be insufficient for filling this role,
+so release candidates are a necessary step in the release process.
+
+Release candidates should be announced in the same way any other release is (ping in the announcements room,
+announcement sent out via the checker, etc), but should be clearly marked as a pre-release. Extra attention to detail
+should be spent ensuring breaking changes are clearly communicated.
+
+### Alphas and Betas
+
+Alphas and betas may be created during any time of the month, and it is recommended to do so after merging a major
+feature, especially if the release candidate cycle is not close to starting. This is not expected to be commonplace, so
+announcing these releases is up to the discretion of the release manager.

src/service/admin/execute.rs

@@ -1,6 +1,4 @@
-use std::io::IsTerminal;
-
-use conduwuit::{Err, Result, debug, debug_info, error, info, warn};
+use conduwuit::{Err, Result, debug, debug_info, error, info};
 use ruma::events::room::message::RoomMessageEventContent;
 use tokio::time::{Duration, sleep};
 
@@ -9,16 +7,10 @@
 pub(super) const SIGNAL: &str = "SIGUSR2";
 
 impl super::Service {
-	/// Possibly spawn the terminal console at startup if configured and a TTY
-	/// is available.
+	/// Possibly spawn the terminal console at startup if configured.
 	pub(super) async fn console_auto_start(&self) {
 		#[cfg(feature = "console")]
 		if self.services.server.config.admin_console_automatic {
-			if !std::io::stdin().is_terminal() {
-				warn!("Console enabled without a tty available; Not enabling console");
-				return;
-			}
-
 			// Allow more of the startup sequence to execute before spawning
 			tokio::task::yield_now().await;
 			self.console.start().await;

src/service/migrations.rs

@@ -882,7 +882,7 @@ async fn split_userid_password(services: &Services) -> Result {
 	drop(cork);
 	info!(?remote_users, "Split userid_password.");
 
-	db["global"].insert(SPLIT_USERID_PASSWORD, []);
+	db["global"].insert(FIXED_LOCAL_INVITE_STATE_MARKER, []);
 	db.db.sort()?;
 	Ok(())
 }
@@ -895,7 +895,5 @@ async fn obliterate_roomsynctoken_shortstatehash_with_extreme_prejudice(
 
 	info!("Cleared roomsynctoken_shortstatehash.");
 
-	services.db["global"].insert(DROP_ROOMSYNCTOKEN_SHORTSTATEHASH, []);
-
 	Ok(())
 }