Home
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
*Interfacein2.xbut this suffix was dropped from3.0onwards
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.
| Version | PHP | Symfony | Release | Bug fix | EOL |
|---|---|---|---|---|---|
| 6.x | 7.2+ | 3.4+, 4.0+ | late 2019 | mid 2020 | early 2024 |
| 7.x | 7.3+ | 3.4+, 4.4+, 5.0+ | mid 2020 | early 2024 | early 2025 |
| 8.x | 8.2+. | 5.4+, 6.0+, 7.0+ | early 2024 | early 2025 | early 2026 |
| 9.x | 8.1+. | 6.4+, 7.0+ | early 2025 | early 2026 | early 2027 |
(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.