Page History

...

1. Announcements
2. Check-in regarding the double meeting format
3. Status of  https://github.com/pwinckles/ocfl-java-parent  move into ocfl Github repo
4. Opportunities to chip in:
   1. API Test Suite PRs
      
      1. https://github.com/fcrepo/Fedora-API-Test-Suite/pulls
   2.  Minimal 4 →5 migration needs testing  and code review:
      1. https://github.com/fcrepo4-exts/fcrepo-upgrade-utils/pull/17
5. Update on Fedora 6 Pilots 
6. Sprint Planning
   
   1. 6.0 Architecture Review
      1. Versioning review from last week:
         1. Clarification of the proposal: 
            1. OCFL transactions always result in new versions;  we will not support unversioned content in Fedora
            2. From Fedora's point of view, the current state of a resource is the most recent version (ie HEAD)
            3. By default Fedora will display only "significant" versions in the list of mementos.
            4. "Significant versions"  are OCFL objects that contain a marker file in the content directory (possibly something like content/.fcrepo/memento)
            5. Implication:  versions cannot be removed ( because removing content from OCFL is likely to be controversial).  Copy/Delete entire OCFL object would be the only way to remove version history.
         2. Questions: 
            1. Is it important to be able to have Memento timestamps synchronized across a multi-object transaction?  In other words, are users going to want to be able to version changes across a single time-slice? 
               Ie: 
                   http://localhost:8080/rest/object1/fcr:versions/20190822122001
                   http://localhost:8080/rest/object2/fcr:versions/20190822122001
                   http://localhost:8080/rest/object3/fcr:versions/20190822122001
      2.  Multi-object transaction implementation ideas
   2. Transaction Sidecar Spec Update
7. Status on organizing a Fedora documentation review
8. Your topic here...

...