[REF] 2.0.0

[blaggacao]

And yet another refactoring intent:

• Cleaner code.
• Easier to maintain.
• Leverage click machinery.
• Doesn't repeat click functionality (like flag defaulting)
• Easier to extend.
• KISS (avoide wrap wrap wrap)
• Additional tests.
• Avoid click API masking.
• More stable.

[codecov[bot]]

Codecov Report

Merging #15 into master will increase coverage by 2.75%. The diff coverage is 95.91%.

@@            Coverage Diff             @@
##           master      #15      +/-   ##
==========================================
+ Coverage   82.95%   85.71%   +2.75%     
==========================================
  Files           4        5       +1     
  Lines         176      196      +20     
  Branches       26       28       +2     
==========================================
+ Hits          146      168      +22     
+ Misses         21       20       -1     
+ Partials        9        8       -1

Impacted Files	Coverage Δ
click_odoo/options.py	100% <100%> (ø)
click_odoo/env.py	85.71% <100%> (+1.58%)	:arrow_up:
click_odoo/__init__.py	100% <100%> (ø)	:arrow_up:
click_odoo/cli.py	93.39% <95.06%> (-0.81%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 5508e9c...1c014e7. Read the comment docs.

[sbidoul]

I still don't understand what problem you are trying to resolve... so I don't see any compelling reason to do such a big, backward incompatible change.

[blaggacao]

I guess this solves #16 and other problems/shortcomings that might arise and have already been solved by click in an elegant way over time.

[blaggacao]

I also feel there is a slight inconsistency in your argument:

• Semver major versions declare backwards incompatible changes.
• Therefore and given it's labeled 2.0.0, it's not a question of "if".

I can see however how the question of "when" is much in favour of a time where adoption is only slowly picking up; that is: asap.

As I said: no need to deprecated 1.x.x just yet. And I'm happy to keep 2.x.x at feature parity, so you don't have to bear the maintenance load.

That's just how other projects usually do things.

[blaggacao]

Concrete suggestion to move on:

• Fork master to 1.x branch
• Accept this PR on master (it's feature par and has some extra tests)
• Decide when problems arise if it's better to migrate downstream or fix in 1.x
• Adopt 2.x for new projects.

I don't see any compelling reason that could be raised against such procedure, given that I offer to forward port fixes and features from 1.x and given the arguments (PR bullet points) in favor of this 2.0.0.

[blaggacao]

Closing as replaced by #17 (for maintainability reasons on my end) , but let's keep discussing it here.