Release/0.0.0

[Gisleburt]

Fixes

• Merged @dkorrel's fix for Id not specified in an update call #11 mentioned in Id not specified in an update call #11 #12
• Removed unused and empty files

Other

• Tidied up code using PHPCS, following PSR-1/PSR-2 standards
• Added a VERSION.md
• Added .gitignore
• Added more quality assurance tools, and fixed the ones that were already there
• Added rules for new QA tools

[Gisleburt]

If anyone wants to use this before it's potentially merged (obviously it might not be), update your composer.json like this:

"repositories": [
  {
    "type": "git",
    "url": "https://github.com/Gisleburt/soap-client.git"
  }
],
"require": {
    ...
    "phpforce/soap-client": "^0.0.0",
    ...
}

If phpforce/soap-client get's a release number above 0.0.0, it'll automatically override my repository.

[ddeboer]

I’m not really a fan of adding all those tools in require-dev. I much prefer a Scrutinizer solution, which centralises quality assurance. I just added this repo to Scrutinizer. Maybe try what this .scrutinizer.yml will yield?

imports:
  - php

tools:
  external_code_coverage: true

[ddeboer]

Nice cleanup! But could you please remove the QA configs (we have Scrutinizer for that) and squash commits? Thanks!

[Gisleburt]

Scrutinizer isn't a tool I've used before, is this something third parties can use before submitting pull requests or end users can use to check against their implementations?

Using those packages in require-dev allows anyone to run them at any time. Other CI tools I've used (Travis, Jenkins and PHPCI (the later of which I wouldn't actually recommend unless you really hate Java)) are all based around using them.

Sorry if it sounds like I'm being stubborn, it's merely a lack of understanding on my part. :)

[ddeboer]

Indeed, Scrutinizer will use those tools, but it has them already available, so they don’t need to be installed. All I’d have to do is create a scrutinizer.yml and let Scrutinizer take care of the rest.

[Gisleburt]

Sorry, I mean how do other people use this to check things over?

[Gisleburt]

So this is entirely my opinion but, if you use standard tools and include them in in require-dev, with the rules included in the repository, then:

• The rules can be used in most CI tools; Travis, Jenkins, Scrutinizer (I assume), PHPCI (...sort of...)
• The rules can be used by contributors to check their work conforms to the defined rules.
• Tests can be used by anyone to check integration (not necessary but some people are paranoid)
• Having the QA tools in require-dev means the shouldn't get installed into production
• Tools can be run before commit from the CLI, increasing quality of commits rather than fixing problems later

[troyharvey]

+1 @Gisleburt @ddeboer

[Gisleburt]

🎂 😄