Release 2.0.0 (#52)

A brand new version of the SDK that has the following features:

* Support to Ruby 2.3+
* Support to more APIs (customer, merchant_order, refund, advanced_payment, etc.)
* Rubocop lint
* Unit tests

.editorconfig

@@ -0,0 +1,10 @@
+# see http://editorconfig.org/
+
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8
+insert_final_newline = true

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,28 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: bug
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+
+- Test case to reproduce the bug.  Try to reproduce in the latest version.
+- Code sample that fails
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Environment (please complete the following information):**
+
+- OS: [e.g. Linux/Mac/Windows]
+- Ruby version: [e.g. 2.3]
+- SDK version: [e.g. 2.0.0]
+
+**Additional context**
+Add any other context about the problem here. [e.g. Links to previous bugs].

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,19 @@
+---
+name: Feature request
+about: Suggest completely new features or minor improvements to existing functionality
+title: ''
+labels: enhancement, proposed
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/workflows/ruby.yml

@@ -9,9 +9,9 @@ name: Ruby
 
 on:
   push:
-    branches: [ gitactions ]
+    branches: [ master ]
   pull_request:
-    branches: [ gitactions ]
+    branches: [ master ]
 
 jobs:
   test:
@@ -29,5 +29,7 @@ jobs:
         ruby-version: 2.6
     - name: Install dependencies
       run: bundle install
+    - name: Rubocop
+      run: rubocop lib
     - name: Run tests
       run: bundle exec rake

.rubocop.yml

@@ -0,0 +1 @@
+inherit_from: .rubocop_todo.yml

.rubocop_todo.yml

@@ -0,0 +1,104 @@
+# This configuration was generated by
+# `rubocop --auto-gen-config`
+# on 2021-01-06 19:35:39 UTC using RuboCop version 1.7.0.
+# The point is for the user to remove these configuration records
+# one by one as the offenses are removed from the code base.
+# Note that changes in the inspected code, or installation of new
+# versions of RuboCop, may require this file to be generated again.
+
+# Offense count: 1
+# Configuration parameters: Include.
+# Include: **/*.gemspec
+Gemspec/RequiredRubyVersion:
+  Exclude:
+    - 'mercadopago.gemspec'
+
+# Offense count: 8
+Lint/SelfAssignment:
+  Exclude:
+    - 'lib/mercadopago/core/mp_base.rb'
+
+# Offense count: 1
+# Cop supports --auto-correct.
+# Configuration parameters: AllowUnusedKeywordArguments, IgnoreEmptyMethods, IgnoreNotImplementedMethods.
+Lint/UnusedMethodArgument:
+  Exclude:
+    - 'lib/mercadopago/resources/disbursement_refund.rb'
+
+# Offense count: 36
+Lint/UselessAssignment:
+  Exclude:
+    - 'examples/instant-payment-notifications/receive-ipn.rb'
+    - 'lib/mercadopago/core/mp_base.rb'
+    - 'lib/mercadopago/http/http_client.rb'
+    - 'lib/mercadopago/resources/advanced_payment.rb'
+    - 'lib/mercadopago/resources/disbursement_refund.rb'
+    - 'tests/test_card.rb'
+    - 'tests/test_card_token.rb'
+
+# Offense count: 2
+# Configuration parameters: IgnoredMethods, CountRepeatedAttributes.
+Metrics/AbcSize:
+  Max: 25
+
+# Offense count: 15
+# Configuration parameters: CountComments, CountAsOne, ExcludedMethods, IgnoredMethods.
+Metrics/MethodLength:
+  Max: 69
+
+# Offense count: 3
+# Configuration parameters: CountKeywordArgs, MaxOptionalParameters.
+Metrics/ParameterLists:
+  Max: 7
+
+# Offense count: 1
+Naming/AccessorMethodName:
+  Exclude:
+    - 'lib/mercadopago/config/request_options.rb'
+
+# Offense count: 6
+# Configuration parameters: ExpectMatchingDefinition, CheckDefinitionPathHierarchy, Regex, IgnoreExecutableScripts, AllowedAcronyms.
+# AllowedAcronyms: CLI, DSL, ACL, API, ASCII, CPU, CSS, DNS, EOF, GUID, HTML, HTTP, HTTPS, ID, IP, JSON, LHS, QPS, RAM, RHS, RPC, SLA, SMTP, SQL, SSH, TCP, TLS, TTL, UDP, UI, UID, UUID, URI, URL, UTF8, VM, XML, XMPP, XSRF, XSS
+Naming/FileName:
+  Exclude:
+    - 'examples/instant-payment-notifications/receive-ipn.rb'
+    - 'examples/payment-search/search-approved-payments.rb'
+    - 'examples/payment-search/search-creditcard-payments.rb'
+    - 'examples/payment-search/search-funded-payments-by-name.rb'
+    - 'examples/payment-search/search-payments-from-email-and-date.rb'
+    - 'examples/payment-search/search-payments.rb'
+
+# Offense count: 23
+# Configuration parameters: EnforcedStyle.
+# SupportedStyles: snake_case, camelCase
+Naming/VariableName:
+  Exclude:
+    - 'examples/checkout-buttons/basic_preference/button.rb'
+    - 'examples/payment-search/search-approved-payments.rb'
+    - 'examples/payment-search/search-creditcard-payments.rb'
+    - 'examples/payment-search/search-funded-payments-by-name.rb'
+    - 'examples/payment-search/search-payments-from-email-and-date.rb'
+    - 'examples/payment-search/search-payments.rb'
+    - 'examples/preapproval-payments/button.rb'
+    - 'lib/mercadopago/config/config.rb'
+
+# Offense count: 7
+Style/ClassVars:
+  Exclude:
+    - 'lib/mercadopago/config/config.rb'
+
+# Offense count: 32
+Style/Documentation:
+  Enabled: false
+
+# Offense count: 2
+Style/IdenticalConditionalBranches:
+  Exclude:
+    - 'examples/instant-payment-notifications/receive-ipn.rb'
+
+# Offense count: 12
+# Cop supports --auto-correct.
+# Configuration parameters: AutoCorrect, AllowHeredoc, AllowURI, URISchemes, IgnoreCopDirectives, IgnoredPatterns.
+# URISchemes: http, https
+Layout/LineLength:
+  Max: 151

.ruby-version

@@ -0,0 +1 @@
+2.7.2

CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [https://contributor-covenant.org/version/1/4][version]
+
+[homepage]: https://contributor-covenant.org
+[version]: https://contributor-covenant.org/version/1/4/

CODING_GUIDELINES.md

@@ -0,0 +1,70 @@
+# Coding Guidelines
+
+The Mercado Pago Ruby SDK is a collaborative effort from the start. The SDK team thinks that contributions from different developer will enrich it's feature set and make it more relevant to the community.
+
+However; absorbing all contributions as-is, while expedient, might lead to difficulties in maintenance of the codebase is left unchecked. Collaborative codebases often establish guidelines for contributors to ensure code remains maintainable over time. The effort to maintain the SDK is no different in this regard so a bit of guidance is in order.
+
+The purpose of this guide is to set a baseline for contributions. These guidelines are not intended to limit the tools at your disposal nor to rewire the way you think but rather to encourage good neighbor behavior.
+
+## Language Guidelines
+
+We use **english** language. This is to be consistent everywhere, and to be considerate with developers that do not speak our native language.
+
+Therefore: source code, comments, documentation, commit messages, review comments, and any other kind of contribution *MUST* use english language.
+
+Typos are unavoidable, but try to reduce them by using a spellchecker. Most IDEs can be configured to run one automatically.
+
+## Code Guidelines
+
+* Set your IDE to follow the [`.editorconfig`](https://editorconfig.org/) in each repository.
+* Follow the [RuboCop Ruby Style Guide](https://github.com/rubocop/ruby-style-guide).
+
+Generally speaking, be conscious when contributing and try following the same style that the code in the SDK already has. If you have any doubts, just ask us!
+
+This rules will be enforced automatically when making a pull requests, and checks will fail if you do not follow them, resulting in your contribution being automatically rejected until fixed.
+
+## Comment Guidelines
+
+Comments in code are a hard thing to write, not because the words are difficult to produce but because it is hard to make relevant comments. Too much of it and people do not read comments (and it obfuscates code reading) and too little of it gives you no recourse but to read large portions of codebase to get insight as to what a feature/codeblock is doing. Both situations are undesirable and efforts should be made at all time to have a please comment reading experience
+
+As a general rule you would have to comment on decisions you made while coding that are not part of any specification.
+
+In particular you should always comment any decision that:
+
+* Departs from common wisdom or convention (The **why's** are necessary).
+* Takes a significant amount of time to produce. A good rule of thumb here is that if you spent more than 1 hour thinking on how to produce a fragment of code that took 2 minutes of wrist time to write you should document your thinking to aid reader and allow for validation.
+* Need to preserve properties of the implementation. This is the case of performance sensitive portions of the codebase, goroutines synchronization, implementations of security primitives, congestion control algorithms, etc.
+
+As a general rule of what not to comment you should avoid:
+
+* Commenting on structure of programs that is already part of a convention, specified or otherwise.
+* Having pedantic explanations of behavior that can be found by immediate examination of the surrounding code artifacts.
+* Commenting on behavior you cannot attest.
+
+### Branching Guidelines
+
+Currently `master` is our only long term branch, below a few suggestions of short term branches naming:
+
+* `hotfix/something-needs-fix`: Small routine patches in code to features already there.
+* `feature/something-new`: A new feature or a change in a existent feature. Beware of breaking changes that would require a major version bump.
+* `doc/improves-documentation-for-this-feature`: If you add or change documentation with no impact to the source code.
+
+### Git Guidelines
+
+All commits **SHOULD** follow the [seven rules of a great Git commit message](https://chris.beams.io/posts/git-commit):
+
+1. Separate subject from body with a blank line.
+2. Limit the subject line to 72 characters.
+3. Capitalize the subject line.
+4. Do not end the subject line with a period.
+5. Use the imperative mood in the subject line.
+6. Wrap the body at 72 characters.
+7. Use the body to explain what and why vs. how.
+
+Commits such as "fix tests", "now it's working" and many other common messages we find usually in code **WON'T** be accepted.
+
+Ideally we would like to enforce these rules, but we are realistic and understand that it might be a big change for some people. So unless deviating heavily from what was stated we might accept your commits even if not following these rules perfectly.
+
+Please avoid taking to much time to deliver code, and always [rebase](https://git-scm.com/docs/git-rebase) your code to avoid reverse merge commits.
+
+When reviewing, check if the PR adheres to [RuboCop Ruby Style Guide](https://github.com/rubocop/ruby-style-guide).