diff options
| -rw-r--r-- | _layouts/page.html | 1 | ||||
| -rw-r--r-- | docs/installing/manual_install.md | 27 | ||||
| -rw-r--r-- | docs/running/upgrading.md | 31 |
3 files changed, 32 insertions, 27 deletions
diff --git a/_layouts/page.html b/_layouts/page.html index 1f6312400..8730573b2 100644 --- a/_layouts/page.html +++ b/_layouts/page.html @@ -40,6 +40,7 @@ layout: default <ul> <li><a href="{{ site.baseurl }}docs/running/admin_manual">Admin manual</a></li> <li><a href="{{ site.baseurl }}docs/running/server">Server checklist</a></li> + <li><a href="{{ site.baseurl }}docs/running/upgrading">Upgrading</a></li> <li><a href="{{ site.baseurl }}docs/running/states">Request states</a></li> </ul> </li> diff --git a/docs/installing/manual_install.md b/docs/installing/manual_install.md index 95bfc1b80..0c6efb1d9 100644 --- a/docs/installing/manual_install.md +++ b/docs/installing/manual_install.md @@ -458,33 +458,6 @@ and so it knows to include that in any absolute urls it serves. We have some [production server best practice notes]({{ site.baseurl}}docs/running/server/). -## Upgrading Alaveteli - -The developer team policy is that the master branch in git should always -contain the latest stable release. Therefore, in production, you should usually -have your software deployed from the master branch, and an upgrade can be -simply `git pull`. - -Patch version increases (e.g. 1.2.3 → 1.2.**4**) should not require any further -action on your part. - -Minor version increases (e.g. 1.2.4 → 1.**3**.0) will usually require further -action. You should read the `CHANGES.md` document to see what's changed since -your last deployment, paying special attention to anything in the "Updgrading" -sections. - -Any upgrade may include new translations strings, i.e. new or altered messages -to the user that need translating to your locale. You should visit Transifex -and try to get your translation up to 100% on each new release. Failure to do -so means that any new words added to the Alaveteli source code will appear in -your website in English by default. If your translations didn't make it to the -latest release, you will need to download the updated `app.po` for your locale -from Transifex and save it in the `locale/` folder. - -You should always run the script `scripts/rails-post-deploy` after each -deployment. This runs any database migrations for you, plus various other -things that can be automated for deployment. - ## Troubleshooting * **Incoming emails aren't appearing in my Alaveteli install** diff --git a/docs/running/upgrading.md b/docs/running/upgrading.md new file mode 100644 index 000000000..dae2244e9 --- /dev/null +++ b/docs/running/upgrading.md @@ -0,0 +1,31 @@ +--- +layout: page +title: Upgrading +--- +## Upgrading Alaveteli + +The developer team policy is that the master branch in git should always +contain the latest stable release. Therefore, in production, you should usually +have your software deployed from the master branch, and an upgrade can be +simply `git pull`. + +Patch version increases (e.g. 1.2.3 → 1.2.**4**) should not require any further +action on your part. + +Minor version increases (e.g. 1.2.4 → 1.**3**.0) will usually require further +action. You should read the [`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) document to see what's changed since +your last deployment, paying special attention to anything in the "Upgrade notes" +sections. + +Any upgrade may include new translations strings, i.e. new or altered messages +to the user that need translating to your locale. You should visit Transifex +and try to get your translation up to 100% on each new release. Failure to do +so means that any new words added to the Alaveteli source code will appear in +your website in English by default. If your translations didn't make it to the +latest release, you will need to download the updated `app.po` for your locale +from Transifex and save it in the `locale/` folder. + +Unless you're using Capistrano for deployment, you should always run the script `scripts/rails-post-deploy` after each +deployment. This runs any database migrations for you, plus various other +things that can be automated for deployment. + |