If you are looking for the user documentation for PhpSpec, this is online at phpspec.net

To make a change to PhpSpec, open a PR directly to the master branch. Contributions to PhpSpec are expected to:

• Improve the tool in a way that encourages a BDD workflow
• Have considered Backward Compatibility with extensions and provided compatibility layers to avoid breaks as much as possible
• Have been driven by examples, so will be accompanied by relevant test coverage

If there is a release in the near future, pull requests may be assigned the milestone of a future release. In these cases they will be merged soon after that release.

• We officially support PSR-2
• New classes should, in most cases, be declared final (this has not been upheld in the past but is the policy going forwards)
• Interfaces currently were named *Interface in 2.x but this suffix was dropped from 3.0 onwards

A major release of PhpSpec will occur roughly once per year. At this point the following will occur:

• Backward Compatibility is not maintained - this means extensions will need to be updated and some user specs may need to be rewritten.
• Minimum PHP version will be updated to reflect the current Actively Supported versions.
• Minimum Symfony component versions will be updated to the latest versions that are in active Bug Fix mode.
• Other dependencies may be bumped, depending on individual projects' policies.
• The previous version will be branched in the repository and go into bugfix mode.
• The version prior to the previous version will be at End of Life and no longer supported (git tags will be preserved indefinitely)

After a new major version is released, serious bugs in older versions will be addressed where possible. If a workaround is possible then documenting this workaround will be considered a fix

After End of Life, the major version of PhpSpec will no longer be supported at all.

This does not mean existing test suites will stop running.

(HHVM support was dropped since 4.0.0)

As of version 3.0, PhpSpec uses pure Semantic Versioning.

To introduce a change that will eventually lead to a BC break you must:

• Define new types rather than changing the contract of existing ones
• Mark the old types as @deprecated
• Provide a compatibility layer to support the usage of the older APIs

In future we may consider triggering deprecation warnings, but this is not currently the case.