1. Mailing Lists
  2. Contributors
  3. Re: v18 early migration work based on master

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: v18 early migration work based on master

Re: v18 early migration work based on master

Avatar

Re: v18 early migration work based on master

by "Graeme Gellatly" <graeme@moahub.nz> - 01/07/2024 22:00:29
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 version
2. add a `$nextVersion-[master|dev]` branch that can be used w/ odoo master for a specific version
3. 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 Orsi

Full 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

Reference