Open jugglinmike opened 4 years ago
My perspective is limited, but here are a few observations to get the ball rolling.
Some benefits:
Some drawbacks:
To me, the drawbacks outweigh the benefits. Reducing the technical expertise available in chapter seems risky (since they'll be less able to diagnose and fix any issues that come up), so that might actually be a non-goal. And I don't know if anyone actually values consistency across chapters.
But again, there's a lot I may be missing! For instance: how many installations are there currently? How many of them share the same Airtable Base?
@jesarshah, @shabbyjoon, @rmeritz, @mariestaver, and I met to discuss this on 2020-06-03. We decided that Airtable's current solution for Block deployment (where all instances are updated simultaneously) is sufficient for Frontline Foods. That means we don't need to design any custom workflows or tooling. I've opened gh-53 to document the relevant steps, leaning on the Airtable Block developer documentation to provide the Airtable-specific commands.
We've been talking about what it means to release an Airtable Block during the Custom Blocks Beta. The documentation describes just one way to release a block: for every installation, someone must run the command
block release
, providing the code they want to release.In other words: the custom block release process is limited to one installation of the block. It's a "pull" based model (Frontline Foods chapters are responsible for "pulling in" new versions when they want them), and there is no "push" based model (where the block's developers would update the installed blocks when a new version was ready).
That said, we may be able to build a push-based process for ourselves. We'd need:
The first presents no problem (we could maintain the list of installation in this project's Git repository). The second may not be desirable for everyone involved.
This begs the question: do the block's maintainers and the Frontline Foods chapter members truly want a push-based release process?