We are pleased to announce the immediate availability of Apigility 1.4.0!
This is our first minor release in over a year, and our largest, feature-wise, to date!
Six weeks ago, we announce Zend Framework 3 availablility. Our efforts since then have been focused on making all Apigility modules forwards compatible with version 3 releases of Zend Framework components. This touched on every Apigility component, and required the addition of a couple new components as well to help with migration.
This update also means that Apigility has adopted the same minimum supported PHP version as Zend Framework itself: 5.6. If you are using an earlier version of PHP, we recommend updating as soon as possible, as earlier versions are no longer supported by the PHP project.
The main takeaway to know is: you can upgrade your existing Apigility applications now, and they will continue to work, albeit with a number of bugfixes and new features!
Additionally, once you've verified your application is working, we have provided a script to update your application to take advantage of Zend Framework v3 components and reduce the overall dependency footprint of your application!
(The 1.5 here refers to the internal version of the zf-apigility-admin module, in which this script is defined.)
Once you've run that script, you will be pinned to version 3 Zend Framework component releases, and no longer have a dependency on the full ZF metapackage.
There are other things you can do as well to modernize your application, and we have created a comprehensive migration document for 1.4 detailing the changes.
We decided to mondernize the Apigility skeleton in the same way that we updated the Zend Framework skeleton application. In particular:
::classnotation in Apigility-generated configuration files by default.
The new skeleton updates Apigility applications to use modern approaches to PHP application structure, and provides better tooling around usage of virtual machines and containers in the development workflow.
This release wraps new releases of every Apigility module. Notable features of these modules include:
ZF\Apigility\Applicationfor handling PHP 7
Moduleclass to their own classes.
Moduleclass to their own classes.
patchList()stub to the REST resource class template, so that it is present by default.
apigility-upgrade-to-1.5, for upgrading an existing Apigility application so that it may use Zend Framework component v3 releases.
Moduleclass. You no longer need to list the
ZF\Apigility\Providermodule in your application module configuration.
zf-configuration.class_name_scalars, allowing you to configure whether or not generated configuration will use
Throwableinstances as well.
Halplugin is now deprecated.
resetEntityHashStack(); this can be used when rendering multiple responses or payloads within the same request cycle to allow re-use of the same entity instances.
Two new modules were added to Apigility:
public/directory, adding an entry to that directory's
.gitignorefile to prevent checking those files into version control. Updates to modules are honored, and removal of a module will remove the files from your source tree.
At this time, Doctrine support for Apigility has not yet been updated. Contributors and collaborators are working with the Doctrine team to ensure the various Zend Framework modules they maintain are updated to work with Zend Framework component v3 releases, while working in parallel on zf-apigility-doctrine and zf-doctrine-querybuilder. We hope to announce support for these in the next few weeks.
Upgrading to the latest versions of Apigility modules, however, should allow you to continue using Doctrine features; you will simply be constrained to Zend Framework component v2 releases.
We had a number of contributors to this release, but wish to call out two individuals in particular:
To everyone who has contributed patches, features, feedback, and documentation: thank you!
Subscribe to this blog via RSS.