Skip to content

Migration to version 19.0 #5363

Open
Open
Migration to version 19.0#5363
Milestone
19.0

Description

@hbrunn
hbrunn
opened on Sep 4, 2025

I'm starting to work on initializing the 19.0 branch this week, with the usual openupgrade_framework and base migration script.

Activity

  1. hbrunn commented on Sep 25, 2025

    @hbrunn
    hbrunn
    on Sep 25, 2025
    MemberAuthor

    @MiquelRForgeFlow I see you created the 19.0 branch manually. Can we delete it and wait until this is created by OCA/repo-maintainer-conf#113? My plan for 19.0 is to make OpenUpgrade a more standard OCA repository to reduce manual work.

  2. MiquelRForgeFlow commented on Sep 26, 2025

    @MiquelRForgeFlow
    MiquelRForgeFlow
    on Sep 26, 2025
    Contributor

    Oh, I created it because I saw some other repos having that branch, like https://github.com/OCA/server-tools/tree/19.0.

  3. hbrunn commented on Sep 26, 2025

    @hbrunn
    hbrunn
    on Sep 26, 2025
    MemberAuthor

    that's because of OCA/repo-maintainer-conf#112. I suggest to remove the manually created branch, and let ocabot do its thing. Are you working on something that you need this branch now? If so, we should sync because I've migrated openupgrade_framework with a few TODOs left and have a base migration that doesn't crash

  4. MiquelRForgeFlow commented on Sep 26, 2025

    @MiquelRForgeFlow
    MiquelRForgeFlow
    on Sep 26, 2025
    Contributor

    Ok, branch deleted.

    Are you working on something that you need this branch now?

    I don't need this branch.

  5. hbrunn
    added this to the 19.0 milestone on Oct 3, 2025

  6. oliverkroener commented on Oct 17, 2025

    @oliverkroener
    oliverkroener
    on Oct 17, 2025

    Hello, @hbrunn is there an estimation of when the update to 19.0 will be available? Thanks for your efforts! Oliver

  7. vdewulf commented on Oct 20, 2025

    @vdewulf
    vdewulf
    on Oct 20, 2025

    Hello, @hbrunn is there an estimation of when the update to 19.0 will be available? Thanks for your efforts! Oliver

    Hello, the objective is to have the scripts available by February 2026 at last. The OpenUpgrade Working Group needs to organize the work and get started. It is ongoing.

    To support this effort, which is partly paid by the OCA, you are invited to become a member (as well as all your team members), sponsor the OCA as a company or (soon) participate in our crowdfunding initiatives.
    https://odoo-community.org/get-involved

  8. oliverkroener commented on Oct 20, 2025

    @oliverkroener
    oliverkroener
    on Oct 20, 2025

    Hello @vdewulf thanks, that sounds great.

    I have just signed up with the community organisation.

    Crowd funding sounds good. Helping otherwise I am not sure, how I could do that at the moment, since the last time I had to do with Odoo was the time when it was called OpenERP, but this might change since we are using Odoo now more an more ...

    Best, Oliver

  9. vdewulf commented on Oct 21, 2025

    @vdewulf
    vdewulf
    on Oct 21, 2025

    @oliverkroener Indeed, I saw your payment coming yesterday. Thanks a lot for your support, very appreciated!
    Financial support is always good, and of course contributing here on GitHub is helpful if you have the knowledge to help. If not, don't worry, we all have different talents and skills! As you are interested in the OpenUpgrade scripts, I suppose you/your team will be testers of the new created scripts. It's always useful to get (well written) feedback to improve them.

    Lot of documentation on how to contribute technically is available here: https://github.com/OCA/maintainer-tools/wiki

    All the best, Virginie

  10. legalsylvain
    pinned this issue on Oct 28, 2025

  11. TheMoroney commented on Feb 28, 2026

    @TheMoroney
    TheMoroney
    on Feb 28, 2026

    Out of curiosity, what is the status the v19 open upgrade scripts? are they stable?

  12. oliverkroener commented on Apr 28, 2026

    @oliverkroener
    oliverkroener
    on Apr 28, 2026

    Hello @TheMoroney I would be curious to know that, too?

  13. hbrunn commented on May 4, 2026

    @hbrunn
    hbrunn
    on May 4, 2026
    MemberAuthor

    it's unclear to me what kind of answer you expect here. The scripts work for the cases they've been tested on, whether they'll work for you, who knows without you testing it?

  14. LuGr-01 commented on May 4, 2026

    @LuGr-01
    LuGr-01
    on May 4, 2026

    Out of curiosity, what is the status the v19 open upgrade scripts? are they stable?

    Hello everyone,

    I have just run the Odoo 19 migration scripts to upgrade from Odoo 18 and encountered the four errors detailed in the attached .md file. After bypassing each one, I was able to use the dashboard as usual and have not noticed any further errors yet. I am not sure if you will encounter the same errors, or if the maintainers will be able to fix them.

    Either way, we are happy that this project exists. Thank you.

    odoo19-failures.md

  15. dnplkndll
    added 2 commits that reference this issue on May 15, 2026

    [19.0][MIG] website_*: complete analyses for 31 uncharted modules

    7cde3bf

    [19.0][MIG] website_*: complete analyses for 31 uncharted modules

    669d568

  16. hbrunn commented on May 26, 2026

    @hbrunn
    hbrunn
    on May 26, 2026
    MemberAuthor

    thank you @LuGr-01 for your input. It would have been more helpful though if you had created issues for the two modules that are already marked as done. The other two are about modules not yet marked as done, so those aren't expected to work in the first place.

    I've fixed (1) and (2) in #5674 and #5675 respectively.

    The workaround listed in (2) is terrible, as this leaves you among others with outdated record rules. With (3) you might or might not have messed up your database, as the Austrian localization isn't in scope of my work and I haven't looked at it.

    Word of advice: It's a really bad idea to use bullshit generators for work on something as sensitive as data migrations, that's asking for trouble down the road. Incidentally, this project currently is flooded with PRs that are nearly entirely bullshit too. Better invest the money wasted on that in the crowdfunding

  17. oliverkroener commented on May 26, 2026

    @oliverkroener
    oliverkroener
    on May 26, 2026

    it's unclear to me what kind of answer you expect here. The scripts work for the cases they've been tested on, whether they'll work for you, who knows without you testing it?

    @hbrunn

    I have joined to OCA this year and I thought that there is as clear Roadmap for the upgrade tool for all major extensions.

    Do I get you right, that this is ongoing process and testing is up to the users themselves?

  18. hbrunn commented on May 26, 2026

    @hbrunn
    hbrunn
    on May 26, 2026
    MemberAuthor

    you do

  19. LuGr-01 commented on May 27, 2026

    @LuGr-01
    LuGr-01
    on May 27, 2026

    thank you @LuGr-01 for your input. It would have been more helpful though if you had created issues for the two modules that are already marked as done. The other two are about modules not yet marked as done, so those aren't expected to work in the first place.

    Thanks @hbrunn for your work.

    Of course, these workarounds are poor and are only intended to allow the entire migration to be run through once to see in which modules errors still occur. I am not that into the codebase after all. This was done on a cloned database in a testing environment – the production database was not affected. That wasn’t clear from my original post. And yes it would have been better to create seperate issues.

    I’m not sure whether my company’s management is willing to support the crowdfunding, but I will bring it up.

  20. BhaveshHeliconia commented on Jul 28, 2026

    @BhaveshHeliconia
    BhaveshHeliconia
    on Jul 28, 2026
    Contributor

    Hi everyone and @hbrunn @MiquelRForgeFlow @pedrobaeza @legalsylvain ,

    I am interested in contributing here.

    I actually started working on hr_recruitment_skills yesterday, but I just noticed that PR #5847 had already been opened for the same module.

    I have checked whether there is a recommended way to check whether someone is already working on a module before starting. I couldn't find anything. Is there any recommended process to help avoid duplicate work in the future?

    Thanks in advance!

  21. hbrunn commented on Jul 28, 2026

    @hbrunn
    hbrunn
    on Jul 28, 2026
    MemberAuthor

    you can open a dummy PR with a note when you're expecting to finish it, then others know somebody is already working on it. And don't forget to review existing PRs

  22. pedrobaeza commented on Jul 28, 2026

    @pedrobaeza
    pedrobaeza
    on Jul 28, 2026
    Member

    People involved here don't usually announce in advance in what they are working, as at the end the development took not so much for most of the scripts (except the "big ones"). But what Holger proposes is an option.

  23. BhaveshHeliconia commented on Jul 28, 2026

    @BhaveshHeliconia
    BhaveshHeliconia
    on Jul 28, 2026
    Contributor

    Thanks a lot, @hbrunn and @pedrobaeza, for your quick response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions