upgrade --patch/--minor/--major #172
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#172
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?
Describe the problem to be solved
upgrade
can only be manually ran.Describe the solution you would like
Add flags to support non-interactive automation.
Design question:
current version: 1.4.1
newest avail. version: 1.5.0
abra recipe upgrade --major thisapp
should it upgrade to 1.5.0? I'd say yes but I'd love some input on that.
once coop-cloud/tagcmp#3 gets merged I'll open a PR to close this issue! In the meantime you can check it out here: https://git.coopcloud.tech/coop-cloud/abra/compare/main...knoflook:recipe-upgrade
I would say rather bail out? In this case, there is no major version available (it should be
2.0.0
if you pass--major
, right?) and the automation should rather try to run--minor
. If I'm reading this right...will review now 💯
this makes sense. I see two approaches to this though:
the first is good because it makes more semantical sense, but when you're upgrading an app you might need to type the command 2 times (to correct for a lack of major upgrade in this case).
My thinking was that if you are ready to do a major version upgrade you're also ready to do a minor version upgrade, so we could just throw a warning there (that the automation can put into its logs). That way we avoid having to invoke the command 2 times manually or having to write error checking on the automation side (it's still possible for an automation script to bail out if it sees a warning, right?)
Yep this all sounds wise 🚀
aight i'll re-write this on tuesday/wednesday then!