Release date: 30 August, 2016

We are proud to announce the release of Fedora 4.6.0.

Resources

• This release has been built against Java 8
• Downloads
• Javadocs

Team

Release Manager

• A. Soroka, the University of Virginia, with special guest star
• Jared Whiklo, University of Manitoba

Developers

• A. Soroka, University of Virginia

• Aaron Birkland, Johns Hopkins University
  

• Unknown User (acoburn), 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

Issue Reporters

• Esmé Cowles

• Andrew Woods

• Unknown User (acoburn)

• 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

Summary

The Fedora 4.6.0 release furthers several major objectives:

• Tighten the definition of the RESTful application programming interface (API)
• Improving the Versioning capability
• Re-establish performance test fixtures
• Improve durability with 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.

Performance and Scale

The Performance and Scale group has been testing various versions of Fedora, including the4.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.

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:

1. Previous versions of Fedora emitted messages with the header org.fcrepo.jms.properties. This header is no longer included in messages.
2. 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#.
3. A new header is included with the name org.fcrepo.jms.resourceType. This header includes all rdf:type values of the resource in question.
4. Previous versions of Fedora emitted header-only messages where each header was prefixed with org.fcrepo.jms. The message 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 [3] 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 [4] (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 [5]. 

Versioning

This release includes several bug fixes related to versioning]:

Web Access Control

Performance

One of Fedora's perennial goals is "improved performance". With this as a focus, a Performance and Scalability working group [10] has progressed in the creation of repeatable, scripted tests that exercise and meter basic read/write operations. The objective of these tests is to reveal application bottlenecks and to track changes in performance as the reference Fedora implementation evolves.

Preservation

From a preservation perspective, this release includes support for alternative backend object stores to the default LevelDB. New configurations now exist for MySQL and PostgreSQL [11].

Housekeeping and Bugfixes

Numerous refactorings, bugfixes, and clean-up tasks were addressed in this release [12]:

References