Merge pull request #38 from danieltoader/sfv5

Symfony 4/5 package compatibility upgrade

Author: danieltoader

.coveralls.yml

@@ -0,0 +1 @@
+service_name: travis-ci

.gitignore

@@ -1,7 +1,7 @@
 /vendor/
-tests/app/cache/*
-tests/app/logs/*
-reports/
-composer.phar
-composer.lock
 .idea/
+build
+bin
+/.phpunit.result.cache
+composer.phar
+composer.lock

.travis.yml

@@ -1,30 +1,45 @@
 language: php
 
+sudo: false
+
 cache:
-  directories:
-  - $HOME/.composer
+    directories:
+        - $HOME/.composer
 
 php:
-    - 7.0
-    - 7.1
-    - 7.2
-
-env:
-    - SYMFONY_VERSION=3.0.*
-    - SYMFONY_VERSION=3.1.*
-    - SYMFONY_VERSION=3.2.*
-    - SYMFONY_VERSION=3.3.*
+    - 7.4
+    - 8.0
+
+matrix:
+    include:
+        -   php: 7.4
+            env:
+                - SYMFONY_VERSION=5.1.*
+                - COMPOSER_FLAGS="--prefer-stable"
+        -   php: 7.4
+            env:
+                - SYMFONY_VERSION=5.2.*
+                - COMPOSER_FLAGS="--prefer-stable"
+        -   php: 8.0
+            env:
+                - SYMFONY_VERSION=5.1.*
+                - COMPOSER_FLAGS="--prefer-stable"
+        -   php: 8.0
+            env:
+                - SYMFONY_VERSION=5.2.*
+                - COMPOSER_FLAGS="--prefer-stable"
 
 before_install:
-  - if [ "$SYMFONY_VERSION" != "" ]; then composer require --no-update symfony/framework-bundle "$SYMFONY_VERSION"; fi
-
-before_script:
-
-  - composer install
+    - if [ "$DEPENDENCIES" = "dev" ]; then perl -pi -e 's/^}$/,"minimum-stability":"dev"}/' composer.json; fi;
+    - |
+        if [ "$SYMFONY_VERSION" != "" ]; then
+            sed -ri 's/"symfony\/([^monolog].+)": "(.+)"/"symfony\/\1": "'$SYMFONY_VERSION'"/' composer.json;
+        fi;
+install:
+    - composer update $COMPOSER_FLAGS
 
 script:
-  - mkdir -p build/logs
-  - vendor/bin/phpunit --coverage-clover build/logs/clover.xml
-
-after_script:
-- php vendor/bin/coveralls -v
+    - composer validate --strict --no-check-lock
+    - mkdir -p build
+    - composer run-script tests
+    - composer run-script build

CODEOWNERS

@@ -0,0 +1,11 @@
+#####################################################
+#
+# List of approvers for EmagTechLabs/cache-bundle
+#
+#####################################################
+#
+# Learn about CODEOWNERS file format:
+#  https://help.github.com/en/articles/about-code-owners
+#
+
+* @danieltoader

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. 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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,57 @@
+# Contributing
+We greatly appreciate your input! We want to make contributing to this project as easy and transparent as possible, 
+whether it is to:
+
+- Report a bug
+- Discuss the current state of the code
+- Submit a fix
+- Propose new features
+- Become a maintainer
+
+We have a simple to follow [code of conduct](CODE_OF_CONDUCT.md), and we kindly ask you to follow it in all your 
+interactions with the project.
+
+## We develop with Github
+We use github to host code, to track issues and feature requests, as well as accept pull requests.
+
+### We use [Github Flow](https://guides.github.com/introduction/flow/index.html)
+All code changes Happen Through Pull Requests. Pull requests are the best way to propose changes to the codebase (we use 
+[Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:
+
+1. Fork the repo and create your branch from `master`.
+2. If you've added code that should be tested, add tests.
+3. If you've changed APIs, update the documentation.
+4. Ensure the test suite passes.
+5. Make sure your code lints.
+6. Issue that pull request!
+
+#### Pull request process
+
+1. Ensure any build dependencies are removed before creating the the Pull Request.
+2. Update the README.md with details regarding the change.
+3. Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would 
+   represent. The versioning scheme we use is [SemVer](http://semver.org/).
+4. The Pull Request will be merged in once you have the sign-off of at least one of the maintainer developers.
+   
+## Any contributions you make will be under the MIT Software License
+In short, when you submit code changes, your submissions are understood to be under the same [MIT License](LICENSE) that 
+covers the project. Feel free to contact the maintainers if that's a concern.
+
+## Report bugs using Github's [issues](https://github.com/eMAGTechLabs/annotation-cache-bundle/issues)
+We use GitHub issues to track public bugs. Report a bug by [opening a new issue](); it's that easy!
+
+## Write bug reports with detail, background, and sample code
+**Great Bug Reports** tend to have:
+
+- A quick summary and/or background
+- Steps to reproduce
+  - Be specific!
+  - Give sample code if you can. 
+- What you expected would happen
+- What actually happens
+- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
+
+People *love* thorough bug reports. I'm not even kidding.
+
+## License
+By contributing, you agree that your contributions will be licensed under its MIT License.

LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2016 eMAG IT Research
+Copyright (c) 2021 eMAG IT Research
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

MAINTAINERS.md

@@ -0,0 +1,7 @@
+# MAINTAINERS
+
+This project is maintained by eMAG Recommendation Team.
+
+Some maintainers for this project are:
+
+- Daniel Toader ([@DanielToader](https://github.com/danieltoader))

MAINTAINERS_GUIDE.md

@@ -0,0 +1,69 @@
+# Maintainers Guide
+
+This guide is intended for maintainers - anybody with commit access to one or
+more repositories.
+
+## Methodology
+
+This repository does not have a traditional release management cycle, but
+should instead be maintained as a useful, working, and polished reference at
+all times. While all work can therefore be focused on the master branch, the
+quality of this branch should never be compromised.
+
+The remainder of this document details how to merge pull requests to the
+repositories.
+
+## Merge approval
+
+The project maintainers use LGTM (Looks Good To Me) in comments on the pull
+request to indicate acceptance prior to merging. A change requires LGTMs from
+two project maintainers. If the code is written by a maintainer, the change
+only requires one additional LGTM.
+
+## Reviewing Pull Requests
+
+We recommend reviewing pull requests directly within GitHub. This allows a
+public commentary on changes, providing transparency for all users. When
+providing feedback be civil, courteous, and kind. Disagreement is fine, so long
+as the discourse is carried out politely. If we see a record of uncivil or
+abusive comments, we will revoke your commit privileges and invite you to leave
+the project.
+
+During your review, consider the following points:
+
+### Does the change have positive impact?
+
+Some proposed changes may not represent a positive impact to the project. Ask
+whether or not the change will make understanding the code easier, or if it
+could simply be a personal preference on the part of the author (see
+[bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)).
+
+Pull requests that do not have a clear positive impact should be closed without
+merging.
+
+### Do the changes make sense?
+
+If you do not understand what the changes are or what they accomplish, ask the
+author for clarification. Ask the author to add comments and/or clarify test
+case names to make the intentions clear.
+
+At times, such clarification will reveal that the author may not be using the
+code correctly, or is unaware of features that accommodate their needs. If you
+feel this is the case, work up a code sample that would address the pull
+request for them, and feel free to close the pull request once they confirm.
+
+### Does the change introduce a new feature?
+
+For any given pull request, ask yourself "is this a new feature?" If so, does
+the pull request (or associated issue) contain narrative indicating the need
+for the feature? If not, ask them to provide that information.
+
+Are new unit tests in place that test all new behaviors introduced? If not, do
+not merge the feature until they are! Is documentation in place for the new
+feature? (See the documentation guidelines). If not do not merge the feature
+until it is! Is the feature necessary for general use cases? Try and keep the
+scope of any given component narrow. If a proposed feature does not fit that
+scope, recommend to the user that they maintain the feature on their own, and
+close the request. You may also recommend that they see if the feature gains
+traction among other users, and suggest they re-submit when they can show such
+support.