Child pages
  • Hydra and Fedora 4 - FAQ
Skip to end of metadata
Go to start of metadata

This page of FAQs is offered for information only.  We shall try to keep it accurate and up to date but offer no warranty that it is fully correct at any given time.


Where can I find out more about Fedora 4?

The Fedora 4 wiki pages can be found here: Fedora Repository Home

DuraSpace also ran a webinar series on Fedora 4 beta pilots; the series is archived at

Does Hydra support the effort to develop Fedora 4?

Yes!  The Hydra Community was, and remains, one of the driving forces behind the development of a Fedora version 4.  From the beginning of that effort Hydra developers have been checking that the new code will serve Hydra's needs and we have had a test installation running against it.


Is Hydra developing new gems to work with Fedora 4?

Fedora v4 is significantly different from v3 and the Fedora APIs have changed significantly.  New versions of the Hydra gems that interact with Fedora are being developed alongside the development of the Fedora 4 code.


What is the timeline for a version of Hydra that will work with Fedora 4?

The Fedora team hopes to have a version 4.0 available by the end of the calendar year 2014 (a beta version is available as of June 2014).  This version of Fedora is intended to support only new installations - there will be no provision for migrating from a Fedora 3.x repository.  We anticipate a first, stable version of a 4.0 compatible Hydra gem-set shortly after the Fedora release.  Fedora 4.1, supporting migration from 3.x, will be released sometime in 2015 and, again, a 4.1 compatible Hydra gem-set will be released shortly after that event.


How long will the Hydra Community support the Fedora 3.x compatible gems that we are using at the moment?

Hydra is in use in a wide variety of institutions and organizations.  It is unrealistic to expect that they will all switch to a Fedora 4 based system quickly.  Indeed, some of the Hydra installations are preservation repositories which are likely to wait some time to be sure of Fedora 4's stability before committing their content to a new system.  Whilst there are Hydra sites using Fedora 3.x compatible gems there is likely to be some level of support for them within the Hydra Community; that said, it is inevitable that over time Hydra developers will concentrate more and more on Fedora 4.x based systems.


When I eventually migrate to Fedora 4 and swap to the Fedora 4 gemset, how much of my local code written around the F3 gemset is likely to break?  

For the most part the changes will be painless.  There are no changes to OM or Solrizer.  We've been very conscious of keeping the old API in place in ActiveFedora and adding deprecations. The primary place you will see issues is in the API for permissions within hydra-access-controls.  These changes were required to move to the RDF based web ACL "standard".   Furthermore, the changes better align with the Rails and ActiveRecord API.   The most difficult part will be moving the data out of Fedora 3 and into Fedora 4.  

For sites beginning Hydra development from scratch

If I’m starting Hydra development anew, should I begin with Fedora 3 or Fedora 4?

  • It is prudent to start with Hydra on Fedora 4:

    • No further development is planned on Fedora 3

    • By starting on Fedora 4 now, you will avoid the need to do any migration from Fedora 3 to Fedora 4.

    • The overwhelming weight of mainline Hydra community development is focused on Fedora 4 as a platform.

For sites maintaining existing Hydra applications...

Will I be able to keep running Hydra on Fedora 3?

  • Yes, everything will continue to work as it does now.

  • However, other dependencies may put you at risk:

    • Java Support

    • Rails Update (possible security issues)

    • Resources could be marshalled to continue to support Fedora 3 and related Hydra versions.

  • New Hydra features / enhancements in the mainline of community development will likely privilege Fedora 4 and may not work with Fedora 3 (e.g., Hydra::Works)  

    • See Hydra community survey poll for what individual institution’s current state and future plans are (after survey results)

    • Note that some apps (Avalon, institution-specific Hydra heads) are on Fedora 3 and will likely continue on their individual arcs

    • And parts of the community may very well self-assemble to provide enhancements and ongoing support of Hydra-on-Fedora 3

  • Fedora 3 is no longer under active development (3.8 is the final Fedora 3.x release)

When should / do I need to move from Fedora 3 to Fedora 4?

  • If you want to take advantage of Fedora 4 and the latest mainline Hydra developments (WebACLs, Hydra::Works, etc.), you should move to Fedora 4 as soon as practical

  • Fedora 4.1 will include migration support from Fedora 3.x. Recommendation: move when Fedora 4.1 is released with Hydra Support™

    • If on ActiveFedora >= 7, move directly to next Fedora 4 with Hydra Support

    • If on ActiveFedora < 7, recommendation:

      • move to AF 7+

      • can call DCE for support

  • If you are proactively moving to / leveraging RDF or Linked Data (RDF-style), you should move to Fedora 4 now (or in December when 4.0 is released), given Fedora 4’s native RDF support, the superior RDF tooling in the latest mainline community developments, and the weight of community interest and activity.

  • Eventually, Hydra on Fedora 3 will become brittle enough and vulnerable to exploits that it will not be advisable to run your apps on this stack. We can’t yet predict this point in time.

When I move to Fedora 4, do I need to move from XML to RDF?

  • No. Fedora 4 accommodates Fedora 3-style XML datastreams.

    • XML will continue to be supported as part of Fedora 4

  • If you are considering a move to Fedora 4 with RDF, you may want to move to Fedora 4 with XML as a first step and then migrate your XML to RDF

  • Note that much of the mainline Hydra community development is currently focused on leveraging RDF for standard Hydra operations.

    • e.g., Hydra rightsMetadata will be expressed in RDF (you won’t need to think about it, though, because migration tools).

    • Hydra:Works will include RDF support for expressing file:item:work relationships

    • etc.

How many other people are in the Hydra on Fedora 3 boat?

  • Great question! A lot! We’ll do a survey to get details, and post results!

  • It is important and useful for those sites running Hydra on Fedora 3 to communicate their status, plans and issues, so that they can leverage each others’ work in moving to Hydra on Fedora 4 (or supporting Hydra on Fedora 3).

  • This discussion will unfold on the list (and Hydra Tech calls)

  • The Fedora 4 community is soliciting features & issues & case studies for specific migration issues & needs.

When I do migrate to Fedora 4, what will I need to change in my technology stack?

  • You will need to move your Hydra components from a Fedora 3 to Fedora 4 stack.

    • The mainline community development includes a new core gem set for Hydra that supports Hydra on Fedora 4 (Active Fedora n+1, ActiveTriples, support for WebACLs, hydra-head, hydra-access-controls, hydra-collections, hydra-derivatives, hydra-works, sufia (any others?))

    • Penn State’s Fedora 4 beta pilot includes a working Hydra stack around Sufia on Fedora 4.

    • We anticipate that other Hydra heads (not just Sufia-based) can and will also adapted to work on F4 with the latest core gems.

  • You will need to move your Hydra objects from Fedora 3 to Fedora 4.

    • Fedora 4.1 will include migration tools

    • If you wish to migrate to Fedora 4 in advance of the 4.1 release, some tools are being developed within the Hydra community:

    • expressing Hydra rightsMetadata in WebACLs may emerge as a common migration tool need (perhaps also shared with Islandora and the larger Fedora 4 community).

Which Hydra gem versions work with which versions of Fedora?

As of November 6, 2014

Hydra on Fedora 3.

The Hydra Gem gives the official, known compatible set of Hydra gems that work with each other. See

Hydra Gem  v 7.1

  • This was last updated in July 2014.

  1. active-fedora ~> 7.1.0

  2. blacklight ~> 5.5.1

  3. hydra-head ~> 7.2.0

  4. jettywrapper ~> 1.8.2

  5. nokogiri ~> 1.6.0

  6. nom-xml ~> 0.5.1

  7. om ~> 3.1.0

  8. rails < 5.0, >= 3.2.15

  9. rsolr ~> 1.0.10

  10. rubydora ~> 1.8.0

  11. solrizer ~> 3.3.0

Hydra on Fedora 4.

Until Fedora 4 is released, there are not stable Hydra gems for working on Fedora 4. The best code branches are currently referenced in the sufia Fedora 4 branch’s dependency (see gemfile, below) see


gem 'kaminari', github: 'harai/kaminari', branch: 'route_prefix_prototype'

gem 'sufia-models', path: './sufia-models'

gem 'sass-rails', '~> 4.0.3'

gem 'active-fedora', github: 'projecthydra/active_fedora', branch: 'fedora-4'

gem 'ldp', github: 'cbeer/ldp'

gem 'hydra-head', github: 'projecthydra/hydra-head', branch: 'fedora-4'

gem 'hydra-collections', github: 'projecthydra-labs/hydra-collections', branch: 'fedora-4'

gem 'hydra-derivatives', github: 'projecthydra-labs/hydra-derivatives', branch: 'fedora-4'


  • No labels