feat: patch/release notes for patches and/or releases

[chillbrodev]

Description

When creating a patch and/or a release, it would be helpful to be able to include notes. These notes would be displayed on the Shorebird web Console..

Perhaps as a starting point, the Shorebird Web Console could show the Git SHA the patch/release was made on as this would help understand what code is tied to what release/patch

This could be an optional command such as --notes where it takes a quoted string of information, similar to how `git commit -m" works.

Apologies if this feature is already discussed elsewhere, I looked around and could not find one. I searched things like "release notes" and "patch notes" under Issues.

Requirements

• User can add optional notes to a release or patch with --notes when using the CLI.

Additional Context

I thought of this feature when reviewing my patches on the Shorebird Web Console for a release and trying to decipher what patch had what code.

[eseidel]

Excellent suggestion. Thanks.

[chillbrodev]

I should have some time in a few weeks to try to take this on as a contribution to shorebird.

[eseidel]

Had a related request just now for some sort of "patch metadata" so they could include things like "this patch is mandatory" which they would detect in their app and then show their "please upgrade" dialog, or similar.

[eseidel]

I think we've had two related requests here:

1. This one, which seems to be about editable metadata for the console?
2. (other bugs?) which seem to be about passing some sort of text or json file along with a patch (e.g. serving patch notes on a per-patch basis).

Confirming this is for #1, correct?

[eseidel]

There is also shorebirdtech/updater#140 which seems to be about providing some sort of API to get information about releases from shorebird's servers.

[chillbrodev]

I think we've had two related requests here:

1. This one, which seems to be about editable metadata for the console?
2. (other bugs?) which seem to be about passing some sort of text or json file along with a patch (e.g. serving patch notes on a per-patch basis).

Confirming this is for #1, correct?

Yes this would be correct statement of what I was asking for, editable metadata in the console.

[eseidel]

We spoke with another customer just now who asked for this from the perspective of wanting to have some way to mark a "critical bug" and force user to upgrade before using the app.

They would also like to have release notes for patches that are not yet installed (e.g. as part of the patch response). A small json blob would be sufficient for them they said.

[chillbrodev]

That also makes sense to me and is sufficient.

[StarProxima]

@chillbrodev @eseidel @felangel Hi, I've been thinking for a long time about how to handle updates and patches in applications in one good way, so that it is possible to set notes and customize any display of information about updates and patches in the UI.

I see it in this #1288 and this shorebirdtech/updater#140 issue the desire to somehow process this and receive information about releases with patches, including for the purpose of displaying some information to users.

I think in order to manage the entire update process flexibly, we need some kind of general config that will list all releases and patches with a release note.
This config can be filled in manually or via ci/cd, it can be placed anywhere, the main thing is that the application always has access to it.

This approach makes it relatively easy to implement many functions (mandatory updates and patches, broken updates and patches, obsolescence notes), some of which were discussed here, at the config and client levels.

I could develop a solution that allows you to work with all this without directly affecting shorebird, but which, I think, can solve some of the problems of its users and not only.

---

I started by describing a possible api here - app_update_checker

The part describing the declaration of shorebird patches in the config is especially important - shorebird patches

What do you think about the structure?

What do you think about all this? Is this able to solve some of the issues under consideration and provide more control overall for updates and patches for users?