1. Mailing Lists
  2. Contributors
  3. Re: Proposal for new workflow, incorporating "Optimistic Merging"

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Proposal for new workflow, incorporating "Optimistic Merging"

Re: Proposal for new workflow, incorporating "Optimistic Merging"

Avatar

Re: Proposal for new workflow, incorporating "Optimistic Merging"

by
Acsone SA/NV, Stéphane Bidoul
- 07/06/2016 10:34:08
Hi Maxime,

On Mon, Jun 6, 2016 at 7:38 PM, Maxime Chambreuil <maxime.chambreuil@gmail.com> wrote:
I think we should first agree on where to install from. We should move our current and new deployments from Github to use packages from http://wheelhouse.odoo-community.org.
Once the development environment is disconnected from the production ones, then we can have the approach we want on Github and try different release process and repo conf. Rolling out different ones in the same time will allow us to benchmark them, see which one works in which situation.

+1 

Working with packaged, released addons must be the way to go. Working on source repos should become the exception rather than the norm (ie when you need the very latest features at the risk of less stability).

FYI, at Acsone, our dev workflow is quickly migrating to that approach and we are phasing-out buildout.

In wheelhouse.odoo-community.org, there is already a distinction between "stable" and "dev" addons in the version number. The mechanism is in place, but it requires people paying attention to version numbers for it to be really effective.
 
The process I would like to experiment is:
  • Document new features and new contributions in Github issues
  • Optimistic merges on 7.0, 8.0 and 9.0 branches
  • Freeze branches before a release to make CI green
  • Update setup directory for mature modules to trigger repackaging and tag the branch with the date ("20160606")
Note the presence of setup.py is mandatory on non-released modules too, so people can do "pip install --editable" or "setup.py develop" to work on the source version when they need to.

Git tagging is the best way to mark a release (and possibly trigger the creation of a stable package, although I think it's better to release manually with a simple command).

Now, while there are addons with independent release cycles in the same repo, tagging is more complex, as tags have a repo scope. So tags would somehow need to include the addon name.

Also, tags should contain the package version rather than a date.

Best regards,

-sbi

Reference