The experience of the incompatibility between OpenRefine 3.8 and the Commons extension 0.1 has reminded me of the really poor state of affairs we are in with our extension system. As we know, extensions break easily, and they can break other parts of OpenRefine easily too. At the moment, we should basically assume that each new minor release of OpenRefine (if not patch release) should be accompanied by new releases for all extensions. Users upgrading to a new version should probably only do so when new versions of the extensions they use have been published, and they need to check that manually. That's really not convenient. That means a lot of people are probably very reluctant to upgrade anything at all if they have some combination that works.
Over the past years, I have been pushing for moving functionality out of OpenRefine into extensions maintained separately (including functionality that I implemented myself and care about being widely accessible and usable, such as the Wikibase extension or the wiki table importer), but I have to say at the moment it's really hard to advocate for writing independent OpenRefine extensions given this state of affairs. It's a really bad experience for users and developers.
So what should we do?
- Renounce to having extensions at all, just implement everything in the main repository? I don't see this as a sustainable option, as it means taking ownership of the maintenance for a lot of functionality and it would be forcing anyone who wants to develop an integration for a particular platform / community to go through us for approval.
- Improve the extension mechanism following the plans outlined above (Tom's plan, or adopting something established like OSGi or pf4j)… I have to say I am a bit daunted by the scale of the task. Assuming we implement one of those proposals, we still have very little isolation guarantees on the front end side. And if after all that we do succeed, we have pinned ourselves down to a very aging stack: it probably wouldn't make sense to migrate to a different frontend framework after that, for instance, since that would immediately break things again.
- Keep the status quo, and add a ton of end-to-end testing on top of it (such as ways for extensions to write Cypress tests for their functionality easily, and perhaps run our existing Cypress test suite with their extension enabled). It feels a bit like band aid and will marginally improve things for users, as we would probably keep breaking compatibility as often, but just make it easier for extension devs to notice that and fix as needed.
- Create a sort of release pipeline (a bit like the one for Wikibase) where we do end-to-end testing for OpenRefine with all extensions that we know of (open source and maintained). We run that before making releases and let people catch up before we publish a new version. It still means some centralization that should ideally not exist with a proper extension system, but it's not like one huge mono-repo that contains everything.
- Stop making changes to OpenRefine. It's guaranteed stability for extensions. And it saves us a lot of time to do other things
It's a bit radical, but I think it would take a while before people can't use it anymore. - Or other ideas?
Actually I do have another idea, but I'll post it over in the thread about breaking changes.