Add a mechanisms to detect a Ghost upgrade

kirrg001 commented 5 years ago

What?

It would be great if we could detect if Ghost was upgraded (on bootstrap). What does that mean? 🤔

As soon as your Ghost blog was updated to a new Ghost version e.g. from 2.1.2 to 2.1.3.

Why?

We could offer a new webhook/action to users, which they can react to e.g. site.upgraded.

We have the ability to share which version your blog was updated from. This could be helpful for an extended messaging system e.g. “what’s new” in Ghost-Admin.

How?

IMO we definitely need to persist the version.

Option 1

We could solve this challenge by storing the Ghost version in the settings table. We have currently two main types:

blog -> settings the user can set/change
core -> hidden information. only accessible for internal usages (!)

I think both don't really fit for this use case, because

it's fine to expose this information to clients
it's not fine to modify the value from outside

That means we either need a new namespace or we re-use blog, but we deny that the user can override this value.

Option 2

Create a new table to store such information e.g. a meta table with just a handlful of generic columns (date,key,value).

I am somehow in favour of this option, because this Ghost version is not really a setting?

The disadvantages of this option are:

it would take longer to implement 🤪
we might not have more use cases for a meta table at the moment?

Model Event - in General

We should use the model layer to get informed when the value has changed. As soon as the value get's updated on bootstrap, we would receive a model event. This event can be listen on for instant reactions e.g. trigger a webhook or insert a notification etc.

The field could be either a stringified JSON object {current: value, previous: value} or alternatively we could store an atomic value and rely on the fact that Bookshelf will tell us the previous value, but this would be a one-time information. The decision depends on the use cases and if we need to access the previous and current value all the time or just on bootstrap.

We already have a strategy in place to insert default core settings values (see) on bootstrap. We just need a very similar logic to add or update a settings value as soon as the value changes.

There are for sure other options available. This is just a first brain dump of how this could be implemented :)

Post implementation cleanup list:

[ ] Clean up Ghost version notifications - https://github.com/TryGhost/Ghost/issues/9875

ErisDS commented 5 years ago

I very much think that this should be stored in the settings table. I think that this information can follow the same pattern as other info stored there, e.g. notifications, which are stored in core but exposed via the notifications API endpoint.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

ErisDS commented 5 years ago

Although not currently scheduled, we need to think about this, perhaps as a 3.0 thing. It's an important underlying piece to being able to do other things to improve Ghost's life cycle, including debugging upgrades.

As we add more major versions, it's gonna be more critical tooooooooo.

TryGhost / Ghost