Skip to content
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

Closed
ErisDS opened this issue Jun 11, 2013 · 5 comments
Closed

Rough upgrade plan #139

ErisDS opened this issue Jun 11, 2013 · 5 comments
Assignees
Milestone

Comments

@ErisDS
Copy link
Member

ErisDS commented Jun 11, 2013

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.

@tgriesser
Copy link
Contributor

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 ghost_migrations table (or something like that) in the db...

@jgable
Copy link
Contributor

jgable commented Jun 16, 2013

How can we make Ghost aware of what version it is?

I think I introduced the version as a setting in #163.

@ErisDS
Copy link
Member Author

ErisDS commented Jun 17, 2013

For now, upgrades will require:

  • backup your data using the export tool
  • overwrite Ghost with latest files
    • should not overwrite the DB as there is no replacement DB file, I'm pretty sure that's true on all OS's but should double check
    • should not overwrite any /content files as there will be no replacements - again I should check, but perhaps upgrades should explicitly only replace core?
    • if you make changes directly to Casper it is to be expected that those be overwritten as you should create your own theme
  • if anything goes wrong, re-import your data.

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.

@JohnONolan
Copy link
Member

Let's flag heavily on vip.tg docs that developers may lose all data when upgrading Ghost

@ghost ghost assigned ErisDS Jun 25, 2013
@ErisDS
Copy link
Member Author

ErisDS commented Jul 11, 2013

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

@ErisDS ErisDS closed this as completed Jul 11, 2013
daniellockyer pushed a commit that referenced this issue Oct 5, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants