CLI support for Ghost 2.0
See original GitHub issueWe will release a new minor CLI version before we release Ghost 2.0. This new CLI version will add support to upgrade your blog to Ghost 2.0. Furthermore the new CLI version will add support to stay on Ghost 1.0.
Changes explained
Install/Update a Ghost 2.0 blog
If you execute ghost update
and your are on 1.0, you will update to the next major. If you are on the next major (Ghost 2.0) and you execute ghost update
you will update to the next Ghost 2.x release.
If you execute ghost install
you will install a Ghost 2.0 blog.
Install/Update a Ghost 1.0 blog
The CLI will add a new flag --v1
. This flag will tell the CLI to either install or update a Ghost 1.0 blog (ghost install --v1
or ghost update --v1
).
e.g. People who are still on LTS need an option to install a Ghost 1.0, because we disallow the jump from LTS to 2.0. We will only support the latest (2.0) and the previous (1.0) version. This is a new general concept we came up with. The same rule applies to GScan.
e.g. If we release a new 1.0 release after the Ghost 2.0 release, you can upgrade your blog to the latest 1.0 release with ghost update --v1
.
Guide to upgrade to Ghost 2.0
The CLI will add a proper support for the migration to Ghost 2.0
- print link to a new migration guide, which explains how the migration works
- scan your theme with GScan
- output the report from GScan
- print a link to the new demo draft post we will ship next week (a post about how the new editor König works)
- the ability to continue/abort the major migration
- if the user continues
- the CLI will download/install Ghost 2.0
- Ghost 2.0 will use the same blog config
- CLI will stop the 1.0 blog
- CLI will start the 2.0 blog
- Ghost 2.0 will bring the blog automatically into maintenance mode
- Ghost 2.0 will then run the migration scripts
- if successful, blog is out of maintenance mode
- we use a net server communication (which is optional and needs to be configured from the outer unit)
- if an error occurs during migrations, knex-migrator will auto rollback, the CLI must react and symlink the previous 1.0 version and start the blog
- we have to send a socket + child event to receive the proper error message
- if the user aborts
- the user stays on Ghost 1.0, nothing happens
Ghost 2.0 will tag this new CLI release as minimum cli engine version in the package.json. This will avoid that people with an older CLI version can update to Ghost 2.0. We want that they can enjoy our guidance to jump to the next major version.
Knex-Migrator
Knex-Migrator will be the main instrument to jump from Ghost 1.0 to Ghost 2.0. We will add migration scripts into Ghost 2.0, which will get executed when the Ghost 2.0 blog starts.
We will move the execution of Knex-Migrator from the CLI to Ghost core. The main reason is that we currently have three components which need to execute knex-migrator: the CLI, local development and Ghost(Pro). We think it makes sense to put it back into Ghost core. Therefor we will add a new condition into the CLI to only execute knex-migrator if the blog is on 1.0. We have to ensure that knex-migrator is still called for Ghost 1.0 blogs.
ghost update
should be smoother
This issue is tracked here.
In discussion
We might force the user to upgrade to the latest Ghost 1.0 version before they can jump to Ghost 2.0. The main reason is that we might remove the 1.0 migration scripts in 2.0. But this is still in discussion.
I thought it makes sense to raise this is as early as possible. If you have any questions or concerns, just leave a comment.
Issue Analytics
- State:
- Created 5 years ago
- Comments:22 (22 by maintainers)
Top GitHub Comments
Please raise all pull requests against the 1.9 branch. Thanks!
Working on that right now! A pre-build would be appreciated 👍