Even though the release process changed a bit, it seems that only the
MINOR version number should be incremented in the master branch until
the next major release.
This avoid confusion when writing upgrade scripts, it should work in any
case and it leaves more room from process improvement.
closesodoo/odoo#93123
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
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).
closesodoo/odoo#47281
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
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.
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
Christophe Monniez