Rework abra recipe release #682

New Issue

iexos · 2025-10-01T10:49:00Z

iexos commented

2025-10-01 10:49:00 +00:00

Following a recent kite-flying session, here is a proposal broken out of #663 for changes to the release command.

This rework shall serve the following purposes:

simplify releasing a new recipe version
enhancing history readability by prohibiting uncommitted changes to be included in the release commit
solving the issue of release tags not being pushed
preparing the base for adding automatic checks before releasing (separate issues)

The proposal is to make the following changes to abra recipe release:

bail out if recipe working directory has uncommitted changes (similar to app deploy without --chaos)
execute functionality of recipe sync, i.e. ask for major/minor/patch and add changes to label
- remove recipe sync command
execute existing functionality of recipe release: ask for release notes/pick up release/next, create the commit, create the tag
publish release without asking for confirmation
- remove --publish flag

Regarding the last point, I imagine there was (is?) a good reason that releasing and publishing were separated. Maybe from a time when catalogue generation was less automatic? I assume this separation is not sensible anymore, please tell me if that is not true.

Following a recent kite-flying session, here is a proposal broken out of [#663](https://git.coopcloud.tech/toolshed/organising/issues/663#issuecomment-22329) for changes to the release command. This rework shall serve the following purposes: 1. simplify releasing a new recipe version 2. enhancing history readability by prohibiting uncommitted changes to be included in the release commit 3. solving the issue of release tags not being pushed 4. preparing the base for adding automatic checks before releasing (separate issues) The proposal is to make the following changes to `abra recipe release`: * bail out if recipe working directory has uncommitted changes (similar to `app deploy` without `--chaos`) * execute functionality of `recipe sync`, i.e. ask for major/minor/patch and add changes to label * remove `recipe sync` command * execute existing functionality of `recipe release`: ask for release notes/pick up `release/next`, create the commit, create the tag * publish release without asking for confirmation * remove `--publish` flag Regarding the last point, I imagine there was (is?) a good reason that releasing and publishing were separated. Maybe from a time when catalogue generation was less automatic? I assume this separation is not sensible anymore, please tell me if that is not true.

👍 4

iexos referenced this issue

2025-10-01 10:52:19 +00:00

Make `recipe release` atomic #683

iexos referenced this issue from toolshed/organising

2025-10-01 11:02:13 +00:00

Improving the recipe release process #663

decentral1se added this to the Abra v0.12 project 2025-10-01 13:21:37 +00:00

decentral1se added the

enhancement

label 2025-10-02 09:11:15 +00:00

decentral1se modified the project from Abra v0.12 to Abra "next"