From 77ce97c13edd55aa5a7a0d76b9e5425c6cf2858d Mon Sep 17 00:00:00 2001 From: decentral1se Date: Mon, 16 Feb 2026 23:35:35 +0100 Subject: [PATCH] docs: wording --- docs/abra/swarm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/abra/swarm.md b/docs/abra/swarm.md index ceea3da..575cf69 100644 --- a/docs/abra/swarm.md +++ b/docs/abra/swarm.md @@ -52,4 +52,4 @@ In practice, this is what we currently rely on Swarm mode for. * A way to namespace services into a deployment, aka a "Docker Stack". This would appear to be a minor implementation detail after all is said and done. It's services all the way down and they have some linked networks/configs/volumes/etc. and a shared naming convention. -* Some way to achieve [Fearless YunoHost-esque fearless upgrades](https://git.coopcloud.tech/toolshed/organising/issues/682#issuecomment-29302). In other words, some predictable way to deploy / upgrade / rollback and some way to intervene when things go wrong. It should be easy to understand for everyone and would enable real stability for operators. I think we want some sort of anti-orchestration implementation which is super simple. +* Some way to achieve [Fearless YunoHost-esque Upgrades](https://git.coopcloud.tech/toolshed/organising/issues/682#issuecomment-29302). In other words, some predictable way to deploy / upgrade / rollback and some way to intervene when things go wrong. It should be easy to understand for everyone and would enable real stability for operators. I think we want some sort of anti-orchestration implementation which is super simple.