Release date: 04 February, 2015
We are proud to announce the release of Fedora 4.1.0
Note: There are some minor configuration naming updates in the 4.1.0 release that are backwards incompatible with 4.0.0.
Please review the detailed description of changes.
Resources
Team
Release Manager
Andrew Woods (DuraSpace)
Developers
- Unknown User (acoburn) (Amherst College)
- A. Soroka (University of Virginia)
- Andrew Woods (DuraSpace)
- Unknown User (escowles@ucsd.edu) (University of California, San Diego)
- Longshou Situ (University of California, San Diego)
- Michael Durbin (University of Virginia)
- Osman Din (Yale University)
- Peter Eichman (University of Maryland)
- Yinlin Chen (Virginia Tech)
Issue Reporters
- Unknown User (acoburn)
- A. Soroka
- Andrew Woods
- Unknown User (escowles@ucsd.edu)
- Evgeni Dimitrov
- Justin Coyne
- Michael Durbin
- Mohamed Mohideen Abdul Rasheed
- Peter Eichman
- Stefano Cossu
Summary
Note on release version number
There has been significant community discussion about the metaphorical "4.1" release of Fedora being the release targeting the features and tooling needed for upgrading from Fedora 3 to 4. However, the upgrade tooling is not a part of this current 4.1.0 release. The current 4.1.0 release includes some backwards incompatible changes that has motivated numbering this version as 4.1.0. Specifically, there were minor naming changes to some of the optional configuration properties as well as naming changes to some of the Fedora ontology terms. A detailed description of these changes is available on the wiki.
Updates
Ontology
The Fedora ontology has been updated and improved in several ways. A number of class and property names have been updated based on naming conventions, and several unused terms have been removed. Additionally, the #indexing vocabulary has been published.
Related JIRA Issues
Performance
Performance continues to be a major priority for Fedora 4, and this release includes two important improvements in this regard. The first is the inclusion of the JBoss Transaction Manager, which (among other things) addressed a memory leak issue with transactions. The second is an improvement to the way blank, intermediate nodes are generated. Maintaining a deep, nested repository hierarchy is a key factor in good performance with Fedora 4, and this improvement ensures that there are never too many nodes beneath a single parent in the repository.
Releated JIRA Issues
Camel module
The fcrepo-camel module, middleware that makes it easier to integrate Fedora 4 with external systems, such as external triplestores, Solr indexes, caching layers, etc., was recently promoted from fcrepo4-labs to the main fcrepo4 GitHub repository. This promotion represents the maturity of the module in terms of code coverage, documentation, and usage within the community. This module allows Fedora 4 to leverage the well-supported Apache Camel project to handle everything from ingest to replication to object enhancement (e.g. generation of image derivatives or metadata extraction): anything that falls under the banner of "asynchronous, event-driven workflows". Users can now make use of the existing Apache Camel ecosystem to build distributed, message passing, soft-realtime, loosely coupled systems that involve Fedora 4.
OAI Provider module
This release includes two improvements to the OAI Provider module. The first is a refactor of the repository querying logic; unnecessary code was removed to make the module more light-weight and easier to maintain. The second improvement allows administrators to configure repository descriptions in OAI responses, such as repository name, administrator email address, and Fedora version number.