How to communicate config/underyling service changes using the n+1 naming scheme #58
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#58
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Consider these cases:
You add an additional
compose.matrix.yml
fortraefik
in which you expose some additional ports. These can be enabled when specifying theMATRIX_PORTS_ENABLED=1
in your.env
file.You update an mariadb underyling service version from
10.5
to11
(major version, could contain breaking changes for end-users).So far, the rough idea was to make a new
_<n+1>
tag but it doesn't quite fit in the sense that new info of a potential breaking change or a new feature is passed on.Maybe we can add a
CHANGELOG.md
for each app? Which we could then look up and show when a n+1 update is getting done?Some related thoughts in #55 (closing in favour of this ticket).
How to communicate config/uderyling service changes using the n+1 naming schemeto How to communicate config/underyling service changes using the n+1 naming schemeThe gitea
1.14.0-rootless
+ new config migration is probably the worst case I've seen so far (🙈). Guaranteed breakage of people and a need to communicate a specific upgrade path with steps. See https://docs.gitea.io/en-us/install-with-docker-rootless/ for more. Have this in mind for something that I'd like to make more clear with abra and as part of this ticket.I've been running
git tag -d ...
and then re-uploading tags while hacking away but I am thinking it'd be nice to addabra recipe gitea release --patch
(or whatever) where it just does ann+1
release and you get a chance to just say "I changed such and such in the config" for the tag commit message.This would mean that we use
n+1
for config changes as well which seems fine?I was thinking then we can use the tag commit message to write upgrade instructions and any stuff to watch out for (can we stuff a template into that commit message from
abra
side?). Then when you runabra deploy
,abra
can just show that tag commit message and then do agit log
between the newest tag and the previous one to show what changed directly. Then we wouldn't have to maintain separate change log entries?If we really wanted a change log, we could generate it from the
git log
, I guess.Let's move to #120.