Defining a release process

[jugglinmike]

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:

• a roster of all the block's installations (it may be installed multiple times per Airtable Base)
• write access to all of the Airtable Bases where the block has been installed

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?

[jugglinmike]

My perspective is limited, but here are a few observations to get the ball rolling.

Some benefits:

• less need for technical expertise in each chapter
• more consistent experience across Frontline Foods chapters
• reduced risk of incompatibilities (e.g. when a new release requires a change to the schema, multiple installations in the same Airtable Base will need to be upgraded at the same time)

Some drawbacks:

• updates could be disorienting for end-users (gh-44 is an early idea to help maintainers preempt such confusion)
• regressions could interrupt work and endanger deadlines

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?

[jugglinmike]

@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.