summaryrefslogtreecommitdiff
path: root/odoo/release.py
AgeCommit message (Collapse)Author
2020-09-28[REL] 14.0Christophe Monniez
2020-08-22[REL] saas-13.5Christophe Monniez
2020-06-15[IMP] core: bump master release version to 13.5Christophe Monniez
closes odoo/odoo#52991 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
2020-04-01[IMP] core: bump master release versionChristophe Monniez
closes odoo/odoo#48737 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
2020-03-11[IMP] core: change master release version.Xavier-Do
Before this, the master version is the next major version without taking intermediate saas versions into account. Depending on the point of view, one or other choice can make more sense. Anyway, master is always closer to next saas than next release. Using next major release can be problematic from a technical reason, mainly for upgrade scripts A simple exemple is to write upgrade scripts for master. The script version will be something like 13.3.1.2 since next saas is saas 13.3 and module version 1.2. The problem here is that installing a database in master will have module versions setted to 14.0.1.2 since release.py indicates that version is 14.0, making it impossible to test an incremental version script 13.3.1.3 in master (will never be executed, 13.3.1.3 < 14.0.1.2) Another exemple is when testing migrations on a not-rebased branch. Hypotetically if all upgrade scripts are linked to a specific version of a module (module version is incremented each time a upgrade script is added), someone using an old version of the master won't have the script 13.3.1.3 executed if current module version is 1.2. (which is not true now since module version will be considered to be 14.0.1.2 (> 13.3.1.2). closes odoo/odoo#47281 Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
2019-10-17[REL] bump master's alpha version post 13 releaseXavier Morel
closes odoo/odoo#38913 Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
2018-10-09[REL] bump alpha versionChristophe Simonis
2018-04-23[REL] back to v12 alphaChristophe Simonis
Seems to be a recurring error...
2018-04-10[REL] saas-11.3Christophe Monniez
2018-01-11[REL] master is back as 12.0 alphaChristophe Simonis
2017-12-12[REL] saas-11.1Simon Lejeune
2017-10-10[MERGE] forward port branch 11.0 up to e1104ac344cChristophe Simonis
2017-10-04[FIX] release: correct version info for masterOlivier Dony
(After forking v11 branch)
2017-10-03[REL] 11.0Olivier Dony
2017-10-03[REF] win32: move to WinPython...Christophe Monniez
Purpose: for multiple reasons (bytecode change in python 3.6, missing files for some packages, py2exe is unmaintained ...) the py2exe solution cannot be used anymore. Odoo for windows will now use a portable Python that will be shipped with the Windows installer. For that purpose, a Winpython 3.6.2 is used. In order to build the Windows installer, a Winpython dir with all the Odoo requirements fullfilled, must exists on the build system (qemu-kvm VM). * nsis installer: - Only the python dir is used to avoid packaging too much stuffs - better compression level - starts the Odoo service using nssm - bump to V11 * change the default win10 build vm path * print a warning when uncomplete addon move * try to force remove of addon path: when the addons are moved to Odoo/addons, it happens that the destination already exists. In that case, the source addon was not deleted, resulting in a uneeded file duplication. * fix version string to avoid invalid chars in windows service * Add requirements adpated for WinPython * package.py now shows the traceback when a build fails * verify that a file exists before publishing * debuild now creates an .xz file instead of .gz * package: use logging module * kvm CPU that works with older versions. * fix a pexpect encoding bug * fix the version to remove special chars '~' which is not appreciated by windows services [REM] win32setup: Remove win32 python service Purpose: Before this commit, the win32 service was managed by an executable builded from those two files with the help of py2xe. The win32 service is now managed by nssm which starts Odoo and therefore, those files are not needed anymore.
2017-09-19[REL] more correct version number for master branchChristophe Simonis
2017-09-15[REL] 10.saas~18Christophe Simonis
2017-07-24[REL] back to v11 alphaChristophe Simonis
2017-07-14[REL] 10.saas~17Simon Lejeune
2017-05-10[FIX] P3: list -> iterable builtins (#16811)xmo-odoo
In Python 3: * various builtins and dict methods were changed to return view/iterable objects rather than lists * and the separate Python 2 view/iterable builtins and methods were removed altogether This is problematic when using these items as list (which the happens repeatedly in Odoo), but more viciously when iterating *multiple times* over them (which also happens, which I've messed up multiple times while writing this, and which is a pain to debug even when you've just created the issue). Convert all code using these to semantics-matching cross-version helper functions to get the LCD behaviour between P2 and P3, and forbid the builtins via lint. issue #8530
2016-11-23[REM] workflow: Remove workflow engine, documentation and testsYannick Tivisse
2016-10-12[MERGE] forward port branch 10.0 up to 0acd63dChristophe Simonis
2016-10-05[REL] 10.0 \o/Christophe Simonis
2016-10-02[FIX] packaging: version infoSimon Lejeune
2016-09-30[REL] 10.0rc1Simon Lejeune
2016-09-06[REL] 9.saas~13Simon Lejeune
2016-09-02[REF] openerp: move `openerp` to `odoo`Raphael Collet