Difference between revisions of "Migration Of Escidoc Data"
(New page: The goal of the Migration procedure is to transform the Escidoc data created and modified with a certain stable Escidoc-core release to the next stable Escidoc-core release. Migration pro...) |
m |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
The goal of the Migration procedure is to transform | Stable Releases: | ||
* The goal of the Migration procedure is to transform data representaion (FOXML) between stable releases. A migration tool will be part of each stabe release, which only supports the migration from the last stable release. A skip of stable releases in the update process is not supported for the near future and not recommended. A downgrade is also not supported. | |||
Developer releases: | |||
* A migration from or between developer builds are not, and will not be, supported. We highly recommend NOT to use developer builds with productive data. | |||
It might be that a developer builds work quite well with the data representation from the latest stable release, but we give no warranty that it will be able to migrate these data afterwards to the next stable release. | |||
Nevertheless, the migration tool will try to convert data objects from developer builds. An object is left out, with an entry in the log file, if converting fails. You will only find converted data object in the new repository. Each objects which could not be converted automatically has to be migrated without tool support. Each object, which was created or updated with a developer build, gets also a log entry if converting was successful. A successful conversion in such cases is not a proof for data consistency. Therefore the application should check each such converted object. | |||
[[Category:eSciDoc]] | |||
Latest revision as of 12:43, 5 January 2011
Stable Releases:
- The goal of the Migration procedure is to transform data representaion (FOXML) between stable releases. A migration tool will be part of each stabe release, which only supports the migration from the last stable release. A skip of stable releases in the update process is not supported for the near future and not recommended. A downgrade is also not supported.
Developer releases:
- A migration from or between developer builds are not, and will not be, supported. We highly recommend NOT to use developer builds with productive data.
It might be that a developer builds work quite well with the data representation from the latest stable release, but we give no warranty that it will be able to migrate these data afterwards to the next stable release. Nevertheless, the migration tool will try to convert data objects from developer builds. An object is left out, with an entry in the log file, if converting fails. You will only find converted data object in the new repository. Each objects which could not be converted automatically has to be migrated without tool support. Each object, which was created or updated with a developer build, gets also a log entry if converting was successful. A successful conversion in such cases is not a proof for data consistency. Therefore the application should check each such converted object.