From 45b9d1ad6df09fccb630f0ad28c8bb86727868c3 Mon Sep 17 00:00:00 2001 From: decentral1se Date: Fri, 27 Mar 2026 14:39:07 +0100 Subject: [PATCH] fix: 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 1bc137b..252107c 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 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. This means we have a "one by one" deployment model which would respect `depends_on` and have explicit way to configure roll backs (instead of it happening whenever Swarm feels like it). 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. This means we have a "one by one" deployment model which would respect `depends_on` and have explicit way to configure rollbacks (instead of it happening whenever Swarm feels like it). 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.