Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As such, the process for moving to the production release of Fedora 6.0 will include both Alpha and Beta releases to ensure the broader community has ample opportunity to confirm the functionality against local needs and use cases, and to provide feedback from local testing.

Alpha

One of the goals with the Fedora 6.0 release is to retain compliance with the featureset found in Fedora 5.1 which includes continuing to be compliant with the Fedora API Specification.

The Alpha release includes the following features:

...

Additionally, the following features will be in the Beta release of Fedora 6.0.0 but are not found in the Alpha:

...

Breaking changes from Fedora 5.x

The following are breaking changes in Fedora 6 that should be considered if porting a client application that interacted with a Fedora 5 repository:

  • API for creating and managing Transactions has changed
  • POST-ing to a URL which does not exist will now create the destination as a pseudo-container, i.e. "ghost node", and create a child node inside of it. Previously, this would result in a 404
  • Memento timestamps may no longer be specified when creating a memento
  • Mementos cannot be deleted
  • ActivityStream Actors, in event notifications, now correctly contain a single type rather than a list of typesAPI for creating and managing Transactions has changed
  • No more http://fedora.info/definitions/v4/repository#hasParent property on nested containers
  • No more http://fedora.info/definitions/v4/repository#writable property on resources

Fedora API Compliance

The One of the goals of the Fedora 6.0 release is to retain compliance with the featureset found in Fedora 5.1 which includes continuing to be compliant with the Fedora API Specification

The Alpha release of Fedora 6 .0-alpha build has the following results when the Fedora API TestSuite is run against it. Before the production release of Fedora 6, we strive to have 100% compliance with this test suite.

Req LevelNum PassNum FailNum Skip% Pass
MUST1427695%
SHOULD385188%
MAY2311896%
Total203132594%

...

Expand
titleTests that are not yet passing in the Alpha release
  • 3.1.3-0: Implementations must allow the ldp:insertedContentRelation property to be set by default to an implementation defined value.
  • 3.1.3-P: Implementations SHOULD allow the ldp:insertedContentRelation property to be set by default to ldp:MemberSubject.
  • 3.10.2-D: A client may include the X-If-State-Token header field in a PUT request to make the request conditional on the resource's current state token matching the client's value.
  • 3.2.1-B: In addition to the requirements of [LDP], an implementation ... may support the value http://www.w3.org/ns/oa#PreferContainedDescriptions for the Prefer header when making GET requests on LDPC resources.
  • 3.6.1-A: Any LDP-RS must support PUT to update statements that are not server-managed triples (as defined in [LDP] 2). [LDP] 4.2.4.1 and 4.2.4.3 remain in effect. (This is a failure of the test suite)
  • 4.1.1-A-1: If no LDPRm is appropriate to the Accept-Datetime value, implementations should return a 406 (Unacceptable).
  • 4.1.2-B: Must support PUT for updating existing LDPRvs
  • 4.2.6: LDPRm resources must support DELETE if DELETE is advertised in OPTIONS (https://github.com/fcrepo/fcrepo/pull/1790)
  • 4.3.3.1-E: If an LDPCv supports POST, a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body.
  • 4.3.3.1-F: If an LDPCv supports POST, a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the datetime given in the Memento-Datetime request header.
  • 6.1: For every resource whose state is changed as a result of an HTTP operation, there MUST be a corresponding notification made available describing that change.
  • 6.2-A: The notification serialization MUST conform to the [activitystreams-core] specification, and each event MUST contain the IRI of the resource and the event type.
  • 6.2-B: Wherever possible, data SHOULD be expressed using the [activitystreams-vocabulary].

For comparison, here is are the results of Fedora 5.1.1 are:

Req LevelNum PassNum FailNum Skip% Pass
MUST1463698%
SHOULD4301100%
MAY30012100%
Total21931999%

Full results can be found at https://fedora.info/spec-tests/.

Upgrading to the Alpha

In conjunction with the Fedora 6.0 Alpha release comes upgrade tooling that allows for migrating Fedora 3, 4 and 5 repositories to Fedora 6.0. Please see the Migrate to Fedora 6 instructions for details on how to perform these upgrades.

Beta

Community integrations

...

The Islandora community will build a new fcrepo container using ISLE and encourage our community to pull it in and test using Fedora 6.  We will manually test integration by walking through our Fedora relevant use cases. We will seek to test:

  • Green-field installations
  • Existing Islandora 8 installations
  • Islandora 7 installations that are migrating into Islandora 8

...

  • How many resources can be ingested into Fedora? How long does it take?
  • How do POST response times change on binary resources as the size of the binaries increases?
  • How do GET/POST response times change as the size of the repository increases?
  • How do GET/POST response times change as on a compound resource as the number of resource versions increases?
  • How do GET response times change on binary resources as the number of binary resources in the repository increases?
  • How do GET response times change on containers as the number of child and/or member resources increases?
  • etc

Feedback

Community testing and feedback is vital during the the Alpha and Beta phases of Fedora 6.0 in order to ensure that the application meets (exceeds?) the needs of production use cases. Any feedback that you have during the testing process will be valuable to know; good or bad. 

Please use any of the project communication channels for sharing your results: Mailing Lists etc.