AVAILABLE: Fedora 4.6.0 Release

Thu, 2016-09-01 10:27 -- carol

From A. Soroka, the University of Virginia

Austin, TX  The Fedora team is proud to announce that Fedora 4.6.0 was released on Augsut 31, 2016 and is now available. Find full release notes (including details of particular tickets and issues addressed) at this URL: https://wiki.duraspace.org/display/FF/Fedora+4.6.0+Release+Notes

Resources
 
This release has been built against Java 8 and requires Java 8
 
Team
 
Release Manager
A. Soroka, the University of Virginia
 
Developers
A. Soroka, University of Virginia
Aaron Birkland, Johns Hopkins University
Aaron Coburn, Amherst College
Aaron Elkiss, University of Michigan
Andrew Woods, DuraSpace
Benjamin Armintor, Columbia University
Bethany Seeger, Amherst College
Bill Branan, DuraSpace
Esme Cowles, Princeton University
Jared Whiklo, University of Manitoba
Michael Durbin, University of Virginia
Michael J. Giarlo, Stanford University
Mirek Simek, University of Chemistry and Technology, Prague
Mohamed Mohideen Abdul Rasheed, University of Maryland
Nick Ruest, York University
Peter Eichman, University of Maryland
Yinlin Chen
 
Issue Reporters
Esmé Cowles
Andrew Woods
Aaron Coburn
Jim Coble
Aaron Birkland
Jared Whiklo
Nick Ruest
Mirek Simek
Benjamin Armintor
David Chandek-Stark
Michael Durbin
Bill Branan
Perry Willett
Michael J. Giarlo
A. Soroka
Scott Prater
Doron Shalvi
Trey Pendragon
Rob Sanderson
Yinlin Chen
 
Summary

The Fedora 4.6.0 release furthers several major objectives:

        • Tighten the definition of the RESTful application programming interface (API)
        • Refining the messaging service
        • Use performance test fixtures to examine the effects of different backends
        • Improve durability by encouraging the use of MySQL and PostgreSQL backends
        • Fix bugs

This release will be the last release built against a version of Modeshape that uses Infinispan for data storage.

Changes

Messaging Interface

As the draft Fedora Messaging (SPI) specification moves toward finalization, the message serialization format has been modified to track the recommendations outlined in this document. This will affect any existing message consumers. There are four significant changes that messaging applications should be aware of:

• Previous versions of Fedora emitted messages with the header org.fcrepo.jms.properties. This header is no longer included in messages.

• Previous versions of Fedora emitted messages with the header org.fcrepo.jms.eventType, using values with the http://fedora.info/   definitions/v4/repository# namespace but which were not defined in the Fedora ontology. The org.fcrepo.jms.eventType header now uses values from the newly published Event ontology: http://fedora.info/definitions/v4/event#.

• A new header is included with the name org.fcrepo.jms.resourceType. This header includes all rdf:type values of the resource in question.
Previous versions of Fedora emitted header-only messages where each header was prefixed with org.fcrepo.jms. The message body serialization now also includes a body formatted in JSON-LD using the PROV namespace. All data found in the JMS headers are also available in the body serialization. Examples of this format can be found here: https://github.com/fcrepo4/fcrepo-event-ontology.

• Please note: the JMS-centric header names are not part of the upcoming messaging specification and may be removed from a future version of the fcrepo-jms module. Messaging clients are strongly encouraged to rely on data in the message body.

Application Programming Interface

One of the technical priorities of Fedora is to define a well-specified application programming interface (API) against which client applications can be written and future server-side implementations can be created. This Fedora API should be clear and detailed enough such that a corresponding technology compatibility kit (TCK) would be able to indicate if any Fedora implementation fulfills or diverges from the specification. With this in mind, several issues were addressed in this release that clean up Fedora's RESTful interaction.

An important particular change to note here is the move to use only weakly-validated ETags for RDF resources, in line with a correct interpretation of the HTTP specifications. This means that such ETags are no longer suitable for use with the If-Match request header.

Performance

The Performance and Scale group has been testing various versions of Fedora, including the 4.6.0 release candidates. Recent work has focused on running our JMeter test plans by multiple sites and testing the impact of using a relational database (MySQL or PostgreSQL) instead of LevelDB. The performance of the databases has been at least as good as LevelDB, and typically scales much better.  In addition, testing has identified scalability issues with containers that link to a large number of other containers, and is working to address that issue. The current status of testing is tracked in the wiki: Performance and Scalability Test Plans.

Preservation

This release includes continuing support for various backend object stores. Default usage of that LevelDB backend has been removed, to encourage the intentional selection of a backend appropriate to the integration in hand.