Winchester, MA The Fedora 4 team is proud to announce the fifth Alpha release of Fedora 4. In the continuing effort to provide rapid access to the quickly growing Fedora 4 feature set, this Alpha release is one of several leading up to the feature-complete Fedora 4 Beta release in June.
Available from the GitHub release 
- Fedora 4 Alpha 5 "One-Click Run" 
- Fedora 4 Alpha 5 web application 
- Fedora 4 Alpha 5 web application with authorization 
- Fedora 4 Alpha 5 JMS indexer webapp 
This release enhanced the object and datastream versioning capability  in two fundamental ways. Specifically, whereas the creation of new versions was previously supported, this release added the logical corollary capability of rolling back to or reverting  to a previous version.
Also, the deletion  of previous versions is now supported.
While the internal search index within Fedora 4 natively supports the ability to reindex on startup, the recommended pattern  for exposing a search experience to repository users did not support the ability to reindex the external Solr or triplestore indices prior to this release. This release introduced an HTTP endpoint  for triggering the reindex of external indices for:
- the entire repository
- a tree of resources within the repository, or
- a single repository resource
Beyond reindexing, this release also demonstrated the configuration  where there are more than one Fedora 4 repositories all feeding events into a single external triplestore.
In the on-going effort to expose repository resources in a standardized, linked-data friendly manner, Fedora 4 continues to keep in step with the maturing Linked Data Platform (LDP) draft specification . Support for appropriate HTTP request headers which allow the user to indicate a preference for the comprehensiveness of triples found in responses was added. Likewise, appropriate HTTP response headers were added that specify paging  information and relationships between parent and child resources in an LDP fashion.
Tests were performed this release focused on the determination of whether there is an impact on object creation speeds with the increase in the number of child resources (object or datastream) under a single parent resource. These tests were run with multiple backend storage configurations to additionally assess what, if any, factor the storage backend plays into performance trends.
Thirty thousand objects (first with 1 KB datastreams, then with 2 MB datastreams) were created at the top level of the repository and individually timed using the following backends:
Although a slight up-tick in per object slowdown was indicated during the 2-MB tests, the trend was not absolutely conclusive. Further tests will be repeated with a greater number of objects.
The test results can be found on the wiki .
Having a comprehensive suite of unit and integration tests affords the Fedora 4 code-base with greater resilience to rippling bugs, demonstrations of expected usage patterns of the APIs and components, as well as enables architectural refactoring to occur with less risk. A focus of this release was to increase our test coverage .
The following are the code coverage statistics at the end of this release.
- Unit tests: 73.1%
- Integration tests: 71.7%
- Overall coverage: 86.0%
Several feature enhancements and bugs were addressed during this release. Bug fixes and application polishing included:
- Added resource locking  for concurrent requests on same resource(s)
- Locking is available at single node and hierarchy tree levels
- Enhanced pluggability of external/internal identifier mappings
- Created a utility  for uploading a sample dataset to a running Fedora 4 repository
- Updated jms-indexer-pluggable integration tests to deploy Fedora webapp in addition to triplestore and indexer webapp
- Enhanced REST-API to return timestamp when creating objects and datastreams
- Improved HTTP caching headers
- Corrected multiple HTTP response codes
- Fixed authorization bug which prevented users with both reader and writer roles from reading a resource
- Fixed benchtool bug which prevented an equal number of HTTP client threads from being created to support the "num threads" option