Skip to Content

Contributors

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 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.

by Simone Orsi - 12:41 - 1 Jul 2024

Follow-Ups

  • Re: Re: v18 early migration work based on master
    Hallo liebe Leute,
    
    Unser Büro ist in der Zeit vom Mo., 5. August bis Mo. 13. August nicht besetzt.
    
    Sobald wir zurück sind, melden wir uns sobald als möglich zurück.
    
    Liebe Grüße und schöne Sommerferien,
    
    Das Team von it-fact
    
    Am 18.07.2024 um 15:02 schrieb David Beal <notifications@odoo-community.org>:
    
    
    > Hi,
    
    > 
    
    > Allowing a PR on a future version is a good way to go further.
    
    > We are in august, and the new version is in October, then we don't have so much time to move, 
    
    > then the roadmap must be short I suppose.
    
    > 
    
    > Regards
    
    > 
    
    > David BEAL
    
    > Akretion
    
    > Consultant ERP Odoo
    
    > 
    
    > 
    
    > Le jeu. 18 juil. 2024 à 11:47, Stéphane Bidoul <notifications@odoo-community.org> a écrit :
    
    > Hm, I don't have a good feeling with merging stuff that is not proven compatible with the real 18.0, that's going to be confusing.
    
    > Also, all the dependency management relies on merged stuff being available on PyPI.
    
    > 
    
    > But that can still be considered in a second step when we have learned to fly with unmerged PRs first.
    
    > 
    
    > -sbi
    
    > 
    
    > On Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:
    
    > Thanks everybody for the feedback :)
    
    > 
    
    > @Stéphane Bidoul regarding
    
    > 
    
    > I'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies. 
    
    > So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI
    
    > 
    
    > I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.
    
    > IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?
    
    > 
    
    > We could also add a non blocking warning test in the CI.
    
    > 
    
    > WDYT?
    
    >  
    
    > 
    
    > On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:
    
    > >  I'd go for branch opt 3 + mod version opt 2.
    
    > 
    
    > +1
    
    > 
    
    > On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
    
    > I think this could be nice.
    
    > 
    
    > I would favor Option 2 for branch naming. This could be an indicator for 
    
    > the OCAbot to behave differently about the version numbers when a PR s 
    
    > merged (and we can have option 1 for module version).
    
    > 
    
    > 
    
    > Alexandre
    
    > 
    
    > 
    
    > On 01/07/2024 12:42, Simone Orsi 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 
    
    > 
    
    > 
    
    > 
    
    > 
    
    > > <https://odoo-community.org/groups/contributors-15>
    
    > 
    
    > 
    
    > 
    
    > 
    
    > > Post to: mailto:contributors@odoo-community.org
    
    > 
    
    > 
    
    > 
    
    > 
    
    > > Unsubscribe: https://odoo-community.org/groups?unsubscribe 
    
    > 
    
    > 
    
    > 
    
    > 
    
    > > <https://odoo-community.org/groups?unsubscribe>
    
    > 
    
    > 
    
    > 
    
    > 
    
    > > 
    
    > 
    
    > 
    
    > 
    
    > 
    
    > 
    
    > -- 
    
    > Alexandre Fayolle
    
    > Senior Software Engineer
    
    > 
    
    > Camptocamp France SAS
    
    > 18 rue du Lac Saint André
    
    > 73 370 Le Bourget-du-Lac
    
    > France
    
    > 
    
    > http://www.camptocamp.com
    
    > 
    
    > _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe
> 
    
    > _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe
> 
    
    > 
    
    > 
    
    > -- 
    
    > 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
> 
    
    > _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe
> 
    

    by Andreas Maurhart - 08:06 - 5 Aug 2024
  • Re: v18 early migration work based on master
    Hi,

    Allowing a PR on a future version is a good way to go further.
    We are in august, and the new version is in October, then we don't have so much time to move, 
    then the roadmap must be short I suppose.

    Regards

    David BEAL
    Consultant ERP Odoo


    Le jeu. 18 juil. 2024 à 11:47, Stéphane Bidoul <notifications@odoo-community.org> a écrit :
    Hm, I don't have a good feeling with merging stuff that is not proven compatible with the real 18.0, that's going to be confusing.
    Also, all the dependency management relies on merged stuff being available on PyPI.

    But that can still be considered in a second step when we have learned to fly with unmerged PRs first.

    -sbi

    On Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:
    Thanks everybody for the feedback :)


    I'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies.
    So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI

    I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.
    IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?

    We could also add a non blocking warning test in the CI.

    WDYT?
     

    On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:
    >  I'd go for branch opt 3 + mod version opt 2.

    +1

    On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
    I think this could be nice.
    
    I would favor Option 2 for branch naming. This could be an indicator for 
    the OCAbot to behave differently about the version numbers when a PR s 
    merged (and we can have option 1 for module version).
    
    
    Alexandre
    
    
    On 01/07/2024 12:42, Simone Orsi 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 
    
    
    
    
    > <https://odoo-community.org/groups/contributors-15>
    
    
    
    
    > Post to: mailto:contributors@odoo-community.org
    
    
    
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe 
    
    
    
    
    > <https://odoo-community.org/groups?unsubscribe>
    
    
    
    
    > 
    
    
    
    
    
    -- 
    Alexandre Fayolle
    Senior Software Engineer
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    
    

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    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


    by David BEAL - 03:01 - 18 Jul 2024
  • Re: v18 early migration work based on master
    Hm, I don't have a good feeling with merging stuff that is not proven compatible with the real 18.0, that's going to be confusing.
    Also, all the dependency management relies on merged stuff being available on PyPI.

    But that can still be considered in a second step when we have learned to fly with unmerged PRs first.

    -sbi

    On Thu, Jul 18, 2024 at 11:23 AM Simone Orsi <simahawk@gmail.com> wrote:
    Thanks everybody for the feedback :)


    I'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies.
    So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI

    I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.
    IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?

    We could also add a non blocking warning test in the CI.

    WDYT?
     

    On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:
    >  I'd go for branch opt 3 + mod version opt 2.

    +1

    On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
    I think this could be nice.
    
    I would favor Option 2 for branch naming. This could be an indicator for 
    the OCAbot to behave differently about the version numbers when a PR s 
    merged (and we can have option 1 for module version).
    
    
    Alexandre
    
    
    On 01/07/2024 12:42, Simone Orsi 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 
    
    
    
    > <https://odoo-community.org/groups/contributors-15>
    
    
    
    > Post to: mailto:contributors@odoo-community.org
    
    
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe 
    
    
    
    > <https://odoo-community.org/groups?unsubscribe>
    
    
    
    > 
    
    
    
    
    -- 
    Alexandre Fayolle
    Senior Software Engineer
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    
    

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.

    by Stéphane Bidoul - 11:46 - 18 Jul 2024
  • Re: v18 early migration work based on master
    Thanks everybody for the feedback :)


    I'd also suggest not merging nor pushing to PyPI until the Odoo 18.0 branch has been created, so work only with git PR references in test-requirements.txt for dependencies.
    So we'd probably need to add protections in the bot to avoid premature merges or pushes to PyPI

    I agree on not pushing to PyPI but we should merge, to not enter a valley of pain later.
    IMO the version of the module should serve as the way to check if it is fully migrated or not and we could update the repo readme generation to make it more visible, same for the module's readme. Maybe a ribbon?

    We could also add a non blocking warning test in the CI.

    WDYT?
     

    On Tue, Jul 16, 2024 at 3:27 PM Mignon, Laurent <notifications@odoo-community.org> wrote:
    >  I'd go for branch opt 3 + mod version opt 2.

    +1

    On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
    I think this could be nice.
    
    I would favor Option 2 for branch naming. This could be an indicator for 
    the OCAbot to behave differently about the version numbers when a PR s 
    merged (and we can have option 1 for module version).
    
    
    Alexandre
    
    
    On 01/07/2024 12:42, Simone Orsi 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 
    
    
    
    > <https://odoo-community.org/groups/contributors-15>
    
    
    
    > Post to: mailto:contributors@odoo-community.org
    
    
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe 
    
    
    
    > <https://odoo-community.org/groups?unsubscribe>
    
    
    
    > 
    
    
    
    
    -- 
    Alexandre Fayolle
    Senior Software Engineer
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    
    

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.

    by Simone Orsi - 11:25 - 18 Jul 2024
  • Re: v18 early migration work based on master
    >  I'd go for branch opt 3 + mod version opt 2.

    +1

    On Tue, Jul 16, 2024 at 2:48 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
    I think this could be nice.
    
    I would favor Option 2 for branch naming. This could be an indicator for 
    the OCAbot to behave differently about the version numbers when a PR s 
    merged (and we can have option 1 for module version).
    
    
    Alexandre
    
    
    On 01/07/2024 12:42, Simone Orsi 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 
    
    
    > <https://odoo-community.org/groups/contributors-15>
    
    
    > Post to: mailto:contributors@odoo-community.org
    
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe 
    
    
    > <https://odoo-community.org/groups?unsubscribe>
    
    
    > 
    
    
    
    -- 
    Alexandre Fayolle
    Senior Software Engineer
    
    Camptocamp France SAS
    18 rue du Lac Saint André
    73 370 Le Bourget-du-Lac
    France
    
    http://www.camptocamp.com
    
    

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe


    by Laurent Mignon - 03:26 - 16 Jul 2024