Merge branch 'release/1.0.0'

.gitignore

@@ -1,3 +1,4 @@
+/vendor
 composer.phar
 composer.lock
-vendor
+.DS_Store

.travis.yml

@@ -1,28 +1,46 @@
 language: php
 
 php:
-  - 5.6
   - 7.0
   - 7.1
-
-sudo: false
+  - nightly
 
 cache:
   directories:
     - $HOME/.composer/cache
 
 env:
   matrix:
-    - COMPOSER_FLAGS="--prefer-lowest"
-    - COMPOSER_FLAGS=""
+    - LARAVEL_VERSION="5.4.*" COMPOSER_FLAGS="--prefer-lowest"
+    - LARAVEL_VERSION="5.4.*" COMPOSER_FLAGS="--prefer-stable"
+    - LARAVEL_VERSION="dev-master" ORCHESTRA_VERSION="dev-master" COMPOSER_FLAGS="--prefer-lowest" MINIMUM_STABILITY="dev"
+    - LARAVEL_VERSION="dev-master" ORCHESTRA_VERSION="dev-master" COMPOSER_FLAGS="--prefer-stable" MINIMUM_STABILITY="dev"
+
+matrix:
+  allow_failures:
+    - php: nightly
+    - env: LARAVEL_VERSION="dev-master" ORCHESTRA_VERSION="dev-master" COMPOSER_FLAGS="--prefer-lowest" MINIMUM_STABILITY="dev"
+    - env: LARAVEL_VERSION="dev-master" ORCHESTRA_VERSION="dev-master" COMPOSER_FLAGS="--prefer-stable" MINIMUM_STABILITY="dev"
+  fast_finish: true
 
 before_install:
   - travis_retry composer self-update
+  - if [[ -n ${MINIMUM_STABILITY} ]]; then composer config minimum-stability ${MINIMUM_STABILITY}; echo "Minimum stability set to ${MINIMUM_STABILITY}"; else echo "Minimum stability left unchanged"; fi
+  - if [[ -n ${ORCHESTRA_VERSION} ]]; then composer require orchestra/testbench=${ORCHESTRA_VERSION} --dev --no-update; else echo "orchestra/testbench version requirement left unchanged"; fi
+  - composer require laravel/framework=${LARAVEL_VERSION} --no-update
 
 install:
   - travis_retry composer update ${COMPOSER_FLAGS} --no-interaction --prefer-dist
 
+script:
+  - vendor/bin/phpunit
+
+branches:
+  only:
+    - master
+    - develop
+
 notifications:
-    email:
-        on_failure: change
-        on_success: never
+  email:
+    on_failure: change
+    on_success: never

CHANGELOG.md

@@ -6,5 +6,15 @@ Updates should follow the [Keep a CHANGELOG](http://keepachangelog.com/) princip
 
 ## Unreleased
 
+## 1.0.0 (2017-07-13)
+
 ### Added
-- Conditional environment service provider
+
+- Added the conditional environment service provider
+- Set up test environment and added tests
+- Written readme and guidelines
+- Added Laravel 5.5 auto-discovery
+
+### Changed
+
+- Renamed service provider to `\SebastiaanLuca\ConditionalProviders\Providers\ConditionalProvidersServiceProvider`

CODE_OF_CONDUCT.md

@@ -0,0 +1,12 @@
+# Code of Conduct
+
+It's simple, really:
+
+- Everyone is welcome to contribute
+- Use common sense at all times
+- Be open to other opinions and constructive criticism
+- Be friendly
+
+Feel like someone's in violation of this? [Contact me directly][link-author-email].
+
+[link-author-email]: mailto:[email protected]

CONTRIBUTING.md

@@ -1,32 +1,21 @@
 # Contributing
 
-Contributions are **welcome** and will be fully **credited**.
+Contributions are very welcome and will be fully credited.
 
-We accept contributions via Pull Requests on [Github](https://github.com/sebastiaanluca/laravel-conditional-providers).
+We accept contributions via pull requests.
 
+## Pull request guidelines
 
-## Pull Requests
+- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - Don't go crazy with the formatting.
 
-- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - The easiest way to apply the conventions is to install [PHP Code Sniffer](http://pear.php.net/package/PHP_CodeSniffer).
-
-- **Add tests!** - Your patch won't be accepted if it doesn't have tests.
+- **Add tests** - Your patch won't be accepted if it doesn't have tests. Don't worry though! Feel free to submit a PR without, we'll help you along the way.
 
 - **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date.
 
 - **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option.
 
-- **Create feature branches** - Don't ask us to pull from your master branch.
+- **Create feature branches** - Don't ask us to pull from your master branch unless it only contains the PR code.
 
 - **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
 
-- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.
-
-
-## Running Tests
-
-``` bash
-$ composer test
-```
-
-
-**Happy coding**!
+- **Send coherent history** - Make sure each commit in your pull request is somewhat meaningful and contains related changes. Don't go overboard by changing a dozen files and doing everything in a single commit.

ISSUE_TEMPLATE.md

@@ -1,27 +1,24 @@
-<!-- Provide a general summary of the issue in the Title above -->
+## Description
 
-## Detailed description
+Make it clear if the issue is a **bug**, an **enhancement** or just a **question**. The easiest way to indicate this is to prefix the title, e.g. `[Question] I have a question`.
 
-Provide a detailed description of the change or addition you are proposing.
+Provide a detailed description of the change or addition you are proposing. Include some screenshots or code examples if possible.
 
-Make it clear if the issue is a bug, an enhancement or just a question.
+### Your environment
 
-## Context
+If you're reporting a bug or asking a specific question, include as many relevant details about your environment so we can reproduce it. The more, the better.
+
+- Package version or last commit
+- Operating system and version
+- PHP version
+- Laravel version
+- Related package versions
+- …
 
-Why is this change important to you? How would you use it?
+## Context
 
-How can it benefit other users?
+Why is this change important to you? How would you use it? How can it benefit other users?
 
 ## Possible implementation
 
 Not obligatory, but suggest an idea for implementing addition or change.
-
-## Your environment
-
-Include as many relevant details about the environment you experienced the bug in and how to reproduce it.
-
-* Version used (e.g. PHP 5.6, HHVM 3):
-* Operating system and version (e.g. Ubuntu 16.04, Windows 7):
-* Link to your project:
-* ...
-* ...

LICENSE.md

@@ -1,6 +1,6 @@
 # The MIT License (MIT)
 
-Copyright (c) 2016 Sebastiaan Luca <[email protected]>
+Copyright (c) 2017 Sebastiaan Luca <[email protected]>
 
 > Permission is hereby granted, free of charge, to any person obtaining a copy
 > of this software and associated documentation files (the "Software"), to deal

PULL_REQUEST_TEMPLATE.md

@@ -1,45 +1,34 @@
-<!--- Provide a general summary of your changes in the Title above -->
+## PR Type
 
-## Description
+What kind of pull request is this? Put an `x` in all the boxes that apply:
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Extend feature (non-breaking change which extends existing functionality)
+- [ ] Change feature (non-breaking change which either changes or refactors existing functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+
+## What does it change?
 
 Describe your changes in detail.
 
-## Motivation and context
+## Why this PR?
 
 Why is this change required? What problem does it solve?
 
-If it fixes an open issue, please link to the issue here (if you write `fixes #num`
-or `closes #num`, the issue will be automatically closed when the pull is accepted.)
-
 ## How has this been tested?
 
-Please describe in detail how you tested your changes.
-
-Include details of your testing environment, and the tests you ran to
-see how your change affects other areas of the code, etc.
-
-## Screenshots (if appropriate)
-
-## Types of changes
-
-What types of changes does your code introduce? Put an `x` in all the boxes that apply:
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to change)
-
-## Checklist:
+Please describe in detail how you tested your changes (or are planning on testing them).
 
-Go over all the following points, and put an `x` in all the boxes that apply.
+## Checklist
 
-Please, please, please, don't send your pull request until all of the boxes are ticked.
+To facilitate merging your change and the approval of this PR, please make sure you've reviewed and applied the following:
 
-- [ ] I have read the **[CONTRIBUTING](CONTRIBUTING.md)** document.
-- [ ] My pull request addresses exactly one patch/feature.
-- [ ] I have created a branch for this patch/feature.
-- [ ] Each individual commit in the pull request is meaningful.
-- [ ] I have added tests to cover my changes.
-- [ ] All new and existing tests passed.
-- [ ] If my change requires a change to the documentation, I have updated it accordingly.
-- [ ] My code follows the code style of this project.
+- This PR addresses exactly one issue
+- All changes were made in a fork of this project (preferably also in a separate branch)
+- It follows the code style of this project
+- Tests were added to cover the changes
+- All previously existing tests still pass
+- If the change to the code requires a change to the documentation, it has been updated accordingly
 
 If you're unsure about any of these, don't hesitate to ask. We're here to help!