This is an installment in an ongoing series of bi-weekly posts on ZF3 development status.
We released another component with version 3.0 stability, zend-stdlib. This release got the major version bump for a number of reasons:
Unless a component depends specifically on the hydrators, it's essentially already forwards-compatible with the new version 3! As such, we'll be gradually updating components that depend on zend-stdlib to depend on
^2.7 || ^3.0.
The past two weeks have been heavily focused on preparing components to be forwards compatible with the version 3 releases of zend-stdlib, zend-eventmanager, and zend-servicemanager. We had several breakthroughs that are enabling these migrations.
First, we can test the different versions via additional Travis-CI jobs. As an example, consider these PHP 5.5 entries from the zend-cache test matrix:
matrix: include: - php: 5.5 env: - EXECUTE_CS_CHECK=true - PECL_INSTALL_APCU='apcu-4.0.8' - php: 5.5 env: - SERVICE_MANAGER_VERSION="^2.7.5" - EVENT_MANAGER_VERSION="^2.6.2" - PECL_INSTALL_APCU='apcu-4.0.8'
Note that in the second entry, we specify specific v2 versions of zend-eventmanager and zend-servicemanager to use.
Later, in our
before_install section, we do the following:
before_install: - if [[ $SERVICE_MANAGER_VERSION != '' ]]; then composer require --no-update "zendframework/zend-servicemanager:$SERVICE_MANAGER_VERSION" ; fi - if [[ $SERVICE_MANAGER_VERSION == '' ]]; then composer require --no-update "zendframework/zend-servicemanager:^3.0.3" ; fi - if [[ $SERVICE_MANAGER_VERSION == '' ]]; then composer remove --dev --no-update zendframework/zend-session ; fi - if [[ $EVENT_MANAGER_VERSION != '' ]]; then composer require --no-update "zendframework/zend-eventmanager:$EVENT_MANAGER_VERSION" ; fi - if [[ $EVENT_MANAGER_VERSION == '' ]]; then composer require --no-update "zendframework/zend-eventmanager:^3.0" ; fi
Essentially, we have two builds. One against the v2 components, and one against the v3 components; the items above force one or the other for the particular build. This allows us to verify that the code works against both versions, and that any later changes require that both versions continue to work.
What about that line to remove dependencies, though?
The tricky part of migration has been unravelling dependencies. If a dependency of a component being migrated also depends on one of the updated components, we have to wait until the dependency is migrated. Or do we?
In many cases, these dependencies are marked as suggestions, and as development dependencies only; they are not hard requirements of the component. Realizing this, we discovered the following workflow:
This means that we're testing specifically that the current component is forwards-compatible with the new versions. Later, once those dependencies are updated, we can re-enable those tests.
Finally, a contributor wrote a trait that we can compose in plugin manager tests to verify that a plugin manager implementation is both v2 and v3 compatible. By adding these to components, we're able to verify with much more confidence that the code works on both versions.
With these findings and tools in place, we were able to complete migration of 16 components these past two weeks, tagging each with new stable versions! These include:
We've made every effort to ensure that these releases continue to work with existing version 2 functionality; however, occasionally, errors occur. If you notice such errors, please report them as soon as you can, with as many details as you can, so we can correct them. Additionally, please be aware that developers are fellow human beings, and be respectful in your communication. Nobody is intentionally trying to break your applications, and contributors desire a smooth migration for you as well.
At this point, we're about half-done with the migrations, and of the remaining half, around half have patches under review. If you want to assist, please review the migrations page to see which patches are need review, and where you might be able to help.
As noted in our last update, Gary Hockin performed an automated migration of our documentation from our reStructuredText sources to per-component Markdown a few weeks ago, and opened issues against each component to guide review of the documentation before publication. We also mentioned a plan to host documentation via GitHub Pages.
As part of the migration process, we decided to review and ready documentation for publication for any component getting a new minor release. This has resulted in new documentation for the following 13 components!
We're very excited about the new documentation, particularly as it's mobile-friendly, and has in-site search!
The following is a list of component releases since the last update, minus those noted in the migration section already. While not all releases are related to ZF3 specifically, this list is intended to detail activity within the organization.
Twig_Extension_GlobalsInterface, to ensure it is forwards-compatible with Twig v2.
InvokableFactoryfor situations when options are passed via a plugin manager, and provides tests for validating plugin managers are ready for both v2 and v3.
^5.3.3 || ^7.0, allowing it to work with any ZF component, in any supported PHP version. It also expands the test matrix to include PHP 7.
NumberFormattertext attributes when using the
DateTimevalidator with different sets of input.
If you want to help:
Many thanks to all the contributors who have provided feedback, patches, reviews, or releases these past two weeks!
Subscribe to this blog via RSS.