- Mailing Lists
- Contributors
- Re: v18 early migration work based on master
Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
Re: v18 early migration work based on master
It is interesting and something we would participate in very shortly. Also, honestly, due to the amount of change this hasn't been widely feasible in the past, but now it probably is. Below is just random things that came to mind to think about. TBH you are way more experienced than me on this stuff so maybe it is irrelevant.
As a technical process goes it is OK although a couple of considerations.
1. CI and OCB.
2. Backports and forward ports
3. Related to above, maybe something special for modules with no change.
4. Open PRs for current version.
I put the 3rd and 4th because for me the biggest most annoying workload is not the migration but all the squaring up needed months afterwards
But in any case the technical side is relatively straightforward and can evolve.
I think the bit which we need to pay a little more attention to is the docs/gotchas and collaboration. Essentially the release changes we know about and the impacts.
In my dream world we would have a relevant branch for Openupgrade at same time but that is honestly a work I don't understand enough to help, but that becomes difficult to maintain as things change. Maybe it is impractical as even stable versions require refreshes thanks to the unstable stable policy on even the current release.
Also for certain repos I think we need an empowered team to make some decisions and make them fast and early. This is going offtopic but it is no secret that a number of modules are in questionable repos, and that a number of repos have become impractically large.
On Mon, 1 Jul 2024, 10:42 pm Simone Orsi, <notifications@odoo-community.org> wrote:
Hi everybody,We would like to start working on migrating some base modules to v18 before it gets released.AFAIR there's no "official" policy for it, if not "do it on your own fork and then open PRs when the release is out".From my POV it would be nice to define one.For the branch, I see these options:1. add a `master` branch that can be used w/ any version2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo master for a specific version3. simply have $nextVersion branch and stick to version policy nr 2 (see below)For the module version:1. append `dev`to the version (eg: 18.0.1.0.0dev)2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the release is out (eg: 18.0.0.0.1)I'd go for branch opt 3 + mod version opt 2.For the test suite: I'm not sure we have a way to run tests against master ATM.Am I missing something?In general, what do you think?--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by "Graeme Gellatly" <graeme@moahub.nz> - 10:04 - 1 Jul 2024
Reference
-
v18 early migration work based on master
Hi everybody,We would like to start working on migrating some base modules to v18 before it gets released.AFAIR there's no "official" policy for it, if not "do it on your own fork and then open PRs when the release is out".From my POV it would be nice to define one.For the branch, I see these options:1. add a `master` branch that can be used w/ any version2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo master for a specific version3. simply have $nextVersion branch and stick to version policy nr 2 (see below)For the module version:1. append `dev`to the version (eg: 18.0.1.0.0dev)2. start w/ a number lesser than 1.0.0 and switch to 1.0.0 only when the release is out (eg: 18.0.0.0.1)I'd go for branch opt 3 + mod version opt 2.For the test suite: I'm not sure we have a way to run tests against master ATM.Am I missing something?In general, what do you think?--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
by Simone Orsi - 12:41 - 1 Jul 2024