Agenda

4.5.1 RC-3 testing status
Strange behavior of Binaries and NonRdfSourceDescriptions (see gist and comment below)
Schedule special-topic meeting on Versioning Spec (pre-requisite reading: Memento spec)
F4 plans for moving to Modeshape5
Release candidate policy
Can we cut a release for fcrepo-build-tools
Upcoming release for fcrepo-camel
Thoughts on multi-tenancy
...
Status of "in-flight" tickets
Expand
Jira
server DuraSpace JIRA
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues 40
jqlQuery filter=13202
serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

...

Minutes

...

Looks like we have agreement on expected behaviour
Last modified date on binary source descriptions is problematic
What should the behaviour be?
Option 1: Collapse last modified info from binary and binary description into a single value
- Seems like a bad choice but fixes broken behaviour
Option 2: Keep these values separate but distinguish between HTTP representation and resource representation
Data from the headers is HTTP-specific: it concerns representations. Data from the body (RDF) is repository-specific: it concerns resources.
Note: In the event that the binary itself is changed (e.g. via a PUT operation), it is expected that all last-modified dates would change: the fedora:lastModified date in the RDF would change, since the binary was modified, as would the HTTP headers corresponding to the binary. Since the RDF in the description would change (in addition to fedora:lastModified, the premis:hasMessageDigest would also change) the HTTP last-modified header corresponding to the RDF description would also need to change (since its representation changed).
Should we distinguish between a change to the binary and a change to the description in the messaging framework?
- This will require further discussion. A binary and its description are 2 different HTTP resources but different aspects of the same Fedora repository resource
- Action: Continue this discussion at the committers meeting at OR2016

We will move forward with spec docs one at a time
Versioning appears to be ready to move forward
- Move into Git repo and use Respec tool
There are 2 options for how versions are created
- Need agreement on this before we move forwrard
- Option 1: Indicate that a resource should be versioned. Any updates create a new version
- Option 2: A parallel resource is a versioning target. POSTing to that resource creates a snapshot on demand
Action: Andrew will send out a Doodle poll to schedule the meeting

Modeshape 5 has been released
No longer uses Infinispan
There is a ticket for moving to Modeshape 5
A migration will be required
- A backup/restore operation is recommended
- Fedora exposes this capability already
- This capability will be deprecated in the future but for now it is useful
We will need to update configurations/dependencies and do a lot of testing
At what point will we support more than one release?
- One that supports Mode4 and one that supports Mode5
- Will we have parallel releases?
- If the migration is smooth, we should encourage everyone to upgrade
- If not, parallel releases may make more sense
Should we use Mode5 to launch Fedora 5?
Should we have separate releases for the implementations and the APIs?
- Need to get all the JCR stuff out of the API
- We would have 2 implementations at first: Mode4 and Mode5
- What would their version numbers be?
- Mode4 could be 4.x and Mode5 could be 1.x
  - fedora-4.6.0-mode5-1.0.0
This is an opportunity to separate the API from the implementation and encourage alternate implementations
Need a new branch for Mode5