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 .
Andrew Woods (DuraSpace)
- Unknown User (acoburn) (Amherst College)
- A. Soroka (University of Virginia)
- Andrew Woods (DuraSpace)
- Unknown User (email@example.com) (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)
- Unknown User (acoburn)
- A. Soroka
- Andrew Woods
- Unknown User (firstname.lastname@example.org)
- Evgeni Dimitrov
- Justin Coyne
- Michael Durbin
- Mohamed Mohideen Abdul Rasheed
- Peter Eichman
- Stefano Cossu
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 
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 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 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 direct blank nodes beneath the point in the repository where blank nodes are created.
Releated JIRA Issues
The fcrepo-camel  module 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, middleware that makes it easier to integrate with external systems, such as external triplestores, Solr indexes, caching layers, etc., 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.
Related JIRA Issues