Page History

...

1. The 4.4.0 release is ready. Andrew Woods is adding release documentation. It is anticipated that an additional release will be cut before the new year.
   1. One development goal has been decoupling fcrepo components, meaning that releases can be decoupled. This should make releases easier. For the bundled modules (fcrepo-audit, fcrepo4-oaipmh, etc) they will still be released with the main fcrepo artifacts, at least until OSGi support is more mature.
   2. There is currently no release tooling for backwards compatibility. A sample dataset would be useful for this, where, e.g. a 4.3.0 dataset is available and a 4.4.0 fedora release candidate is installed on top of that.
   3. This could form the start of a test compatibility kit (TCK), which would be focused on the specified fedora API. For example, create a set of resources through the REST API, then verify that the resources were created. This would be in addition to existing integration tests. The existing integration tests would tend to be more implementation-specific than a TCK.
   4. One issue that emerged in the release related to the use of SNAPSHOT versions in the deployment of fcrepo-camel-toolbox in karaf. It seems that pax-exam would help with this. Jared Whiklo is making progress on this.
   5. Esmé Cowles will do some basic testing of 4.4.0 on top of an existing 4.3.0 dataset.
2. Goals for the remainder of 2015
   1. Shrinking the codebase. Extracting fcrepo-transform from the core codebase is nearly complete (see

      Jira
      server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1670

      ), fcrepo-mint may be another candidate for moving to fcrepo4-exts.
   2. Scalability: establishing metrics, storage options for different usage patterns.  Unknown User (daniel-dgi) is interested in testing a distributed installation (especially: a sharded Modeshape storage layer and handling very large files).  Esmé Cowles is interested in testing the limits of a single-node fedora instance. For this, we need something concrete at which to aim: baseline benchmarks, goals, metrics, etc. Using a reference dataset would be useful.
      
      1. For this, we need a plan so that the people interested in this aren't duplicating efforts. The fcrepo-test-grinder project may be useful for establishing a shared baseline, though the project hasn't been actively maintained recently.
      2. A special topics meeting could be focused on setting up a common environment that can be used for these benchmark tests. Andrew Woods will send out a poll to meet about this next week.
   3. Backup: serializing data to disk.
   4. Separating API from the implementation and versioning separately.
3. Esmé Cowles to chair next week's meeting in Andrew Woods' absence.