CHANGELOG.md

[kayakr]

In order to ensure continued operation of existing Islandora 8 sites
as a Developer
I would like to read an up-to-date summary of changes.

Now that there are Islandora sites in operation, changes to the codebase that introduce new or changed behaviour need to be documented in an agreed location. I'd like to see something for Islandora along the lines of d.o changes, e.g. https://www.drupal.org/list-changes/drupal

A recent case that affected an operational site is the change of IIIF manifest endpoint at https://github.com/Islandora/islandora_defaults/pull/10/files#diff-dc6beea1be1765f0bdcfcb8ac0a44058R31
I understand branch 8.x-1.x is a dev branch, but it would still be good to have changes clearly documented.
Other recent changes include the new queuing for REST OAI-PMH, or the media multifile stuff in islandora/islandora.

[elizoller]

In general, I agree some sort of changelog would be helpful, at least for point releases.

Related to https://github.com/Islandora/islandora_defaults/pull/10/files#diff-dc6beea1be1765f0bdcfcb8ac0a44058R31 - i am wondering it it makes more sense in this case to revert that URL back to manifest and then change the new manifest url for single objects to something else like single-manifest (open to suggestions). I probably shouldn't have changed it to begin with. @kayakr would it best for you if i change it back?

[kayakr]

@elizoller I'm not too fussed about the specific change re iiif manifest. Once identified it's an easy change to apply.

I'm more concerned about the wider practice of the Islandora community regarding communication around a rapidly evolving set of components and behaviours.

Right now it feels like one has to inspect each commit to know what's changing, and I would find it preferable to have some kind of changelog or summary to advise on what changes are significant, or might break functionality for systems in production.

[dannylamb]

I think the challenge here is just figuring out how to integrate this concept with our workflow. At some point either the contributor or the reviewer will have to realize that this change is significant enough to warrant a changelog entry. And then we have to figure out a way to assemble all of them to be published with the release.

As always, it's not a technical problem, but a people/process problem. I'm totally open to ideas on how we do this, because quite frankly, I don't know what the best path forward is. I can always do something and then we adjust over time, but it'd be good to collaboratively work through this.