How to communicate config/underyling service changes using the n+1 naming scheme #58

New Issue

2021-04-07T12:45:09Z

decentral1se commented

2021-04-07 12:45:09 +00:00

Consider these cases:

You add an additional compose.matrix.yml for traefik in which you expose some additional ports. These can be enabled when specifying the MATRIX_PORTS_ENABLED=1 in your .env file.
You update an mariadb underyling service version from 10.5 to 11 (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).

Consider these cases: - You add an additional `compose.matrix.yml` for `traefik` in which you expose some additional ports. These can be enabled when specifying the `MATRIX_PORTS_ENABLED=1` in your `.env` file. - You update an mariadb underyling service version from `10.5` to `11` (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).

decentral1se added this to the (deleted) milestone 2021-04-07 12:45:09 +00:00

decentral1se added the design label 2021-04-07 12:45:09 +00:00

decentral1se referenced this issue

2021-04-07 12:45:22 +00:00

Ensure users know what is happening with updated versions coming down the pipes #55

decentral1se changed title from ~~How to communicate config/uderyling service changes using the n+1 naming scheme~~ to How to communicate config/underyling service changes using the n+1 naming scheme

2021-04-07 12:45:32 +00:00

decentral1se commented

2021-04-13 15:03:09 +00:00

The 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.

The 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.

decentral1se added this to the (deleted) project 2021-04-30 07:32:14 +00:00

decentral1se commented

2021-04-30 07:39:09 +00:00

I've been running git tag -d ... and then re-uploading tags while hacking away but I am thinking it'd be nice to add abra recipe gitea release --patch (or whatever) where it just does an n+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 run abra deploy, abra can just show that tag commit message and then do a git 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.

I've been running `git tag -d ...` and then re-uploading tags while hacking away but I am thinking it'd be nice to add `abra recipe gitea release --patch` (or whatever) where it just does an `n+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 run `abra deploy`, `abra` can just show that tag commit message and then do a `git 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.

❤️ 1

decentral1se added this to the (deleted) milestone 2021-09-09 14:30:55 +00:00

decentral1se commented

2021-09-09 14:31:37 +00:00