Hi, as early Tryton integrators and contributors from version 0.0.1 we collected some experiences with the API migrations from version to version, which we want to share with you and talk about.
We think it is a benefit for all Tryton developers to be able to migrate their modules as soon as possible. At the same time it should be a huge benefit for the framework itself to ease migration as much as possible resulting in a) more time left for other contributions and b) increased attractiveness of the framework due to lower maintenance costs. API-Migration Recipes --------------------- As we have a lot of custom modules running in several production environments it is essential for us to have reliable and repeatable procedures to be able to perform (or repeat) a migration at any moment. We are doing this by collecting the migration steps to perform for a next major release together with the documentation of recipes (whenever possible). Some steps can easily be automated, others need intense manual intervention. Find our schedule for the migration from 2.0 to 2.1 published at [1]. Depending on the number and complexity of the necessary steps API migrations can be very time-consuming. It was the case for the past migration from 2.0 to 2.1 [1], but can also be remembered for others e.g. the migration from version 1.4 to 1.6 with the adaption to the usage of PYSON [2] combined with new transaction management[3]. Why we should make migrations more calculable --------------------------------------------- Doing a quick evaluation of the migration steps to expect for version 2.4 we are currently seeing as expensive - change of wizard design (done [4]) - removal of name in ir.property (done [5]) - support of different tables for property fields (goal) - remove workflow (goal) - change format of __tryton__.py (goal) - add button definition on models instead on view (goal) - replace nested view by reference id (in review [6]) From our experiences we are already a little bit scared about the time and effort this next migration will cost. We are convinced, that the best and most economic way to do our internal migration would be during the feature freeze just before a major release. This would combine upstream testing and internal testing, thus being profitable for all sides: - Intensive testing of the upcoming release - Early migration of our modules - Increased proximity to trunk - Less operating expense - More free resources for contributions It is clear, that this schedule only has a chance to work, when the expected and the real effort of the migration will fit into the feature freeze. If we are not able to know the effort or if we estimate the effort being to big, we have to choose a later moment to jump to the next version - with the disadvantages depicted above. Propositions ------------ We see the following ways to take the line: - Optimized planning of the release cycles with respect to features affording time consuming migration - Joined efforts to establish and maintain the knowledge base [1] - Stopping to accept changes with time consuming migration efforts if there is already enough of such efforts for the next release. The big and time consuming API changes should be better planned and allocated to several releases, thus enabling integrators to follow the Tryton release cycle. The migration effort for the next release with the wizard change in our estimation will already be a substantial challenge, that could be enough for one release cycle. Besides the overall limitation of migration effort per release we should add another freeze like 'No more changes affording big migration efforts within the last 2 weeks before the complete freeze' to give integrators the chance to estimate migration efforts and begin the migration a little bit earlier - for the benefit of all. The maintenance of the migration recipes should be as close as possible to the development of Tryton. This means, when there is an API change being migrated in the upstream modules, we should already collect the knowledge about the necessary steps to do. We think this would be a great step with big benefit for the whole community. Any input, as usual, highly appreciated! | [1] http://http://code.google.com/p/tryton/wiki/Migration_2_0 | [2] http://hg.tryton.org/trytond/rev/403ba0f2a1e5 | [3] http://hg.tryton.org/trytond/rev/08e1868e307c | [4] http://hg.tryton.org/trytond/rev/12cb56cc422a | [5] http://hg.tryton.org/trytond/rev/fe4cebd8de84 | [6] http://codereview.tryton.org/226004/ -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
