e3fee2cf46
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
47 lines
2.6 KiB
ReStructuredText
47 lines
2.6 KiB
ReStructuredText
|
|
=====================
|
|
Upgrade your database
|
|
=====================
|
|
|
|
.. _odoosh-advanced-upgrade_your_database:
|
|
|
|
1. Download and Upload your database
|
|
------------------------------------
|
|
|
|
Download a dump of your database (from the :ref:`Builds view <odoosh-gettingstarted-builds-download-dump>`), choose the
|
|
exact copy and without filestore options. Upload the .sql.gz dump on https://upgrade.odoo.com/upload and
|
|
select the Testing Purpose. If you have custom code, you can choose to have it upgraded by us, or do it yourself. Once
|
|
it's processed, you'll get a dump of the database in return.
|
|
|
|
.. Warning::
|
|
|
|
Do *not* upload *backups* of your production database (found in the Backups tab of the production branch) as these are incompatible with the Upgrade platform - they contain your complete sources, etc. that are not needed for the upgrade. Make sure to download a **Dump** instead - either through the Backups tab using the *Download Dump* button or through the Builds page by using the *Download Dump* entry of the contextual menu of your latest production build.
|
|
|
|
2. Test your upgraded database
|
|
------------------------------
|
|
|
|
Create a staging branch that will run the upgraded database. Either make sure your production branch's code is
|
|
compatible between the two Odoo versions and fork your production branch, or make a new staging branch containing
|
|
the upgraded code.
|
|
|
|
Once the staging build is done (it doesn't matter if it failed due to the version incompatibility), import your
|
|
upgraded dump in the backups tab of the branch. The platform will automatically detect the version of the dump and
|
|
change the version of Odoo's source code to the corresponding version for the build.
|
|
|
|
Test the upgraded database and make sure everything runs as it's supposed to.
|
|
|
|
3. Replace your existing production database
|
|
--------------------------------------------
|
|
|
|
Once you've tested everything and you're satisfied, start the process over to get an up-to-date upgraded dump:
|
|
|
|
* Make a new dump of your production database (as described in step 1)
|
|
* Upload it on upgrade.odoo.com and select the Production purpose
|
|
* Receive the newly upgraded dump and import it in your production branch. The build might get marked as failed because
|
|
the platform will run it with the upgraded databases' Odoo version together with the old custom code.
|
|
* Merge or commit the upgraded custom code in the production branch
|
|
|
|
If anything goes wrong, remember you can restore a backup. The platform will always make one before you make any
|
|
Odoo.sh operation on the production database. If the restored backup comes from a previous version, the platform will
|
|
detect it and change the project's Odoo version back if it needs to.
|