Ensure users know what is happening with updated versions coming down the pipes #55
Labels
No Label
automation
bug
community organising
democracy
design
documentation
duplicate
enhancement
finance
funding
help wanted
invalid
publishing
question
security
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#55
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?
Now that we'll have the generation script publishing the versions (see coop-cloud/abra#121), we will have to deal packagers publishing versions.
Some of those versions will be straight upgrades of the
app
service. Then users know what is coming for them. However, some of those will be updates to the underlying services and then the version tags add a~<n>
to them.Taking Gitea for example, if we upgrade the database with a major version, we'd publish this new version
1.13.4~1
but that doesn't quite show that it is potentially breaking change.So, one way to mitigate this will be to use
CHANGELOG.md
files in the app repos. Another way is to explain exactly what is going on via https://docs.cloud.autonomic.zone/packager-guide/#how-apps-are-versioned. And the other way is to make sureabra
shows what versions are being deployed when an update goes out.Leaving this open to track the implementation of these thoughts.
Let's converge on #58 (more specific).