Have a bot do the module version bumping

[StefanRijnhart]

Please make version bumping a task of some git bot instead of making it a part of the PR. By making it a part of the PR, lots of trivial and unnecessary conflicts are brought upon the poor contributor and the poor person trying to scape his deployment together from different unmerged feature branches. I have no need for version bumping myself (except in the rare case when in need of a migration script) as I am used to working with git hashes, but I understand the pip folks need it to pinpoint the desired patch level. But please let a script do the work so that it does not affect the flurry of PRs that has always made the OCA thrive.

[lasley]

By making it a part of the PR, lots of trivial and unnecessary conflicts are brought upon the poor contributor and the poor person trying to scape his deployment together from different unmerged feature branches.

Fully agreed.

but I understand the pip folks need it to pinpoint the desired patch level.

From what I understand, this is already managed automatically for PIP. AFAIK the module version in manifest has the following purposes:

• Describes to Odoo when to trigger certain migration folders
• Canonical representation in:
  • Repo-level ReadMe
  • Within Odoo (and the apps store)

Assuming the above, I don't think that the actual version numbers are incredibly important - outside of the first point about the migrations. Something reasonably simple, such as simply increasing fix version numbers if a change to the version hasn't been made in the PR I think would be acceptable.

[StefanRijnhart]

So version increments are not needed for pip style deployments? @sbidoul can you confirm?

[hbrunn]

I would be quite surprised by this too, because I thought that's why we do the dance in the first place.

Anyways, also for reasons of proper referencing (and hopefully some time depending on) an addon version we need to be more exact with that. But yes, I also start encountering conflicts because of the version change, we forget it all the time so that it's still not trustworthy, both very good reasons to automate this away.

How about a web hook for the push event in pseudo python:

if all('!no_version_change!' in commit['message'] for commit in commits):
    return
elif any('!database_schema_change!' in commit['message'] for commit in commits):
    # increase x from https://github.com/OCA/maintainer-tools/blob/master/CONTRIBUTING.md#version-numbers
elif any('!new_feature!' in  commit['message'] for commit in commits):
    # increase y
else:
    # increase z

push(new_commit)

I don't mind changing the phrasing or where to exactly specify the information, but I think we need something like this anyways. And with the infrastructure in place, we surely can think of other nice things to do with the OCA odoo picking up commands from commit messages...

[hbrunn]

(and a few hardcoded exclusion criteria like ignoring transbot pushes and the like)

[sbidoul]

setuptools-odoo autoincrements the package version using a 'dev' component in the version number. Here is an example. So it's not necessary to increment the version number manually to benefit from pip freeze.

To pip install dev versions, pip install --pre must be used.

It is of course important to increment version number manually to communicate semver style information to users.

Note in the modules I maintain, I don't require contributors to bump versions in their pull requests. I consider it's not their duty, but rather mine as a maintainer. So I do that when merging.

Regarding a bot doing that, I'm not sure. How would a bot distinguish between a bug fix and a new feature?

[hbrunn]

as proposed in #314 (comment) - minor fix by default, new feature or database breakage depending on keywords in the commit message

[StefanRijnhart]

@sbidoul thanks for the clarification! How exactly do you increase the version number at merge time? Do you merge on the command line?

[sbidoul]

Do you merge on the command line?

Yes, I try to at least. Or when I forget I push a bump version commit.

[sbidoul]

keywords in the commit message

In the merge commit message then? So it means only the bot can merge?

[hbrunn]

no, it means we write a webhook that github calls when there's a push event (what merging an MR is). The hook must check probably some configuration if the auto versioning is in effect for some project for some target branch.
It will receive a description of the commits being pushed, and based on this and above configuration it would push an extra commit or not.

[lasley]

I think a hook is a good idea here. Is this something we would look to host on odoo-community.org, alongside the Github connector? I made a solid PoC for abstract webhooks in OCA/webhook#4, which we have in a few production deploys at this point.

The hook must check probably some configuration if the auto versioning is in effect for some project for some target branch.

Assuming it's a module addition to the connector, we could add an option inside of Odoo to disable it at the repo or even module level.

It will receive a description of the commits being pushed, and based on this and above configuration it would push an extra commit or not.

Any idea how to identify a merge push vs a regular push? I'm in the Github Docs, and I don't really see anything helpful. We may need to use a Git post-merge hook instead.

[hbrunn]

github wont allow us to run git hooks on their infrastructure... I'm not aware of a way to distinguish a merge from a direct push via the API. But I also don't see why that's relevant given we exclude users like transbot and add the possibility to turn version increases off in the commit message. And yes, sure, the oca odoo instance will provide the hook then

[guewen]

Thanks for creating the issue! I tweeted about that some time ago: https://twitter.com/guewenb/status/922384175352737792

I'm quite interested in the way they do with Rust Lang:

• http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/
• https://github.com/barosl/homu/

The workflow is the following:

1. A pull request is approved by a reviewer, the approval is addressed to the bot by a comment, such as @bors r+1.
2. The bot maintains an ordered queue of pull requests approved for merge
3. For each pull request, it rerun the tests on top of master
4. If successful, the bot proceeds with the merge

I see at least 3 points of interest:

• When the bot merge, it can changes the version. Details about what version digit (patch, minor, ...) has to be changed can be specified in the comment addressed to the point by the reviewer @bot r+1, version: minor
• As the build is rerun on master before merging, no longer build failing because the pull request is two months old
• No conflict on version number