Implement dynamic versioning for 2 or 3 MeltanoLabs-managed connectors.

[aaronsteers]

One challenge in maintaining multiple connectors is the tension between:

1. We want to release pinnable versions often so that users can pin be in the practice of pinning to version IDs and not pip install from main branch.
2. Even in a fully automated release cycle, there's at least one PR and repo 'version bump' needed before the release can be published.

This approach would eliminate the second requirement, so we could in theory release new versions without needing to commit a version bump change back to the repo:

• https://github.com/mtkennerly/poetry-dynamic-versioning

From the readme:

Poetry's typical version setting is still required in [tool.poetry], but you are encouraged to use version = "0.0.0" as a standard placeholder.

With the minimal configuration above, the plugin will automatically take effect when you run commands such as poetry build. It will update the version in pyproject.toml, then revert the change when the plugin deactivates. If you want to include a __version__ variable in your code, just put a placeholder in the appropriate file and configure the plugin to update it (see below) if it isn't one of the defaults. You are encouraged to use __version__ = "0.0.0" as a standard placeholder.

[edgarrmondragon]

@aaronsteers with dynamic versioning in place, would users be installing from a git tag instead of the default branch?

[WillDaSilva]

@edgarrmondragon If they installed from a branch instead of a tag, depending on how we configure the tool, they'd either get a dirty version (e.g. 1.2.3-dev0.acdf123), or the nearest tag upstream of the commit they installed from. Installing from a tag would be best, as is already the case imo except when doing rapid development with a new repository.

[edgarrmondragon]

@WillDaSilva ah, that's nice. So if I understand the use case correctly, once a user publishes a new release & tag from the GitHub UI a workflow is triggered with the following steps:

• Checkout the repo
• poetry build, this will create the assets with the version pulled from the latest tag (created by the release)
• Attach wheel to GitHub release
• Publish to PyPI

This seems like a good approach, and we could probably make it even easier for each repo by wrapping the workflow described above in a reusable action.

cc @aaronsteers

[WillDaSilva]

@edgarrmondragon Yup. It wouldn't surprise me if such a workflow was already available on the marketplace as an action. It has the benefit of running the workflow for the release/tag itself, so there's no risk of drift between the commit that updates the version, and the commit that gets built into the published wheel/images.

Note that this approach only works if building directly git already works, so it wouldn't, for instance, work for Meltano because we have to build the UI prior to building the wheel.

[aaronsteers]

@kgpayne - It occurs to me that tap-snowflake and target-snowflake would be good 'first repos' to try this approach with. What do you think of trying this there with those two repos, and we can use those as a learning opportunity?

[visch]

Certainly could try it, very low risk no one's using this right now! :D

[aaronsteers]

Closing as complete. For example implementations, see

• feat: implement poetry-dynamic-versioning tap-snowflake#7
• feat: implement poetry dynamic versioning tap-messagebird#15
• feat: implement poetry dynamic versioning tap-dbt#95

Fantastic work, @kgpayne ! 🚀