Using embedded collection views with each one using a CollectionCoordinator would cause an infinite loop in responds(to:).

Maybe it's better to check in responds(to:)? I don't know if there are other scenarios this could happen in.

It looks like there's been a breaking API change compared to 1.0.1, albeit a small one.

ArraySection.updateDelegate was already weak and looking at the memory graph this is causing circular references

This is a copy/paste from https://github.com/JosephDuffy/Persist/, with a couple of small tweaks:

• Only tests iOS; macOS, tvOS, and watchOS were removed
• Coverage is not uploaded to Codecov; I don't have permission to add the project
• Xcode 11.5 is used; this is the latest stable version
• v2 of the cache action is used; this is the latest stable version

It will do the following:

• Perform a release when a tag starting with v is pushed
  • v0* or v*- (e.g. v1.1.0-rc1) will be marked as pre-release
• Build and upload docs to the gh-pages branch as part of releases
• Run tests against iOS when a commit is pushed

Note that the cache is not as useful as it could be right now; Swift likes to rebuild things based on inodes so the cache is largely (maybe entirely) discarded, but will be useful in a future Swift release.

You'll need to create an orphaned gh-pages branch for the docs since I don't have permissions. I don't think it needs an initial commit, although maybe you can't push an empty branch? I've never tried.

Basic Sections were not propagating updates if added via a call to invalidateAll. This is to address #2.

The issue can be recreated by using a SegmentedSectionProvider when switching to a segment that contains a Section (SectionProvider works I think)

This commit alone is likely not enough to fix this issue; updateDelegate should probably be set to nil for removed Sections, and should probably be set in more places.