-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rough upgrade plan #139
Comments
I've got a basic migrations branch implementation here... still needs a bit of work, but ultimately I'm trying to make it in Knex so someone can call the migrations programmatically and have the migration state based off of a |
I think I introduced the version as a setting in #163. |
For now, upgrades will require:
I think this is reasonably sound, and given we're only at 0.2.0, not even an alpha really, people should expect things to go wrong & that the upgrade process might be painful for a while. Given that there is no code for this, I'm going to move this issue out of 0.1.1 but not close it as it may warrant further discussion. |
Let's flag heavily on vip.tg docs that developers may lose all data when upgrading Ghost |
We have basic import and export features, and the ability to redeploy a Ghost instance reasonably easily as the deploy script works over and over. There have been many breaking changes over the past 2-3 weeks, so I have written rough instruction on how to do an upgrade without losing data. It does require a bit of manual labour, but should work. Warning, I've not actually tested this yet! https://github.com/TryGhost/Ghost/wiki/Updating-Deployed-Ghost-Instances |
refs https://github.com/TryGhost/Team/issues/579 A new setting `members_signup_access` can be set to `invite` by the site owner which explicitly makes Portal to behave invite only, this change updates Portal to handle the setting
Need to put together a rough plan of what upgrading Ghost is going to look like in the future.
How will database migrations work - how can we know what version a particular database is?
How can we make Ghost aware of what version it is?
How do we protect the database from being overridden?
How do we protect files in the custom content folder?
For now this is probably just a discussion that will result in some documentation & issues for implementing proper database migration etc.
The text was updated successfully, but these errors were encountered: