bflad
commented
2 years ago Listing out some potential options and quick analysis:
Proposal 1: Do Nothing
The terraform-provider-scaffolding repository remains as-is using terraform-plugin-sdk until that project is potentially archived in the future.
Pros: No time or effort required. Cons: Continued lack of terraform-plugin-framework discoverability from this journey path. Slower onboarding for provider developers wishing to create and publish from this framework.
Proposal 2: Create terraform-provider-scaffolding Branch
A new branch, e.g. framework, is added to the existing terraform-provider-scaffolding repository that is reimplemented using this framework. Later, this new branch can be merged into the main branch.
Pros: Some discoverability due to being in the existing repository. Provider developers can onboard faster using the new framework (just the same as the existing framework). Cons: Still appears to recommend terraform-plugin-sdk. Switching branch to switch framework may not be obvious and may require extra steps after copying the template.
Proposal 3: Branch Existing terraform-provider-scaffolding
The existing terraform-provider-scaffolding repository main branch is moved into its own new branch, e.g. sdkv2. The main branch is reimplemented using this framework. Later, the other branch could potentially be deleted.
Pros: Discoverability due to being in the existing repository. Provider developers can onboard faster using the new framework (just the same as the existing framework). Cons: For those wishing to still use the old framework, switching branch may not be obvious and may require extra steps after copying the template.
Proposal 4: Overwrite Existing terraform-provider-scaffolding
The existing terraform-provider-scaffolding repository main branch is reimplemented using this framework.
Pros: Discoverability due to being in the existing repository. Provider developers can onboard faster using the new framework. Cons: For those wishing to still use the old framework, it is harder to onboard.
Proposal 5: Create Separate Template Repository
Spin up a separate template repository, e.g. terraform-provider-scaffolding-framework, that is built on this framework. Later, the code could be migrated to the existing repository or the existing repository is archived.
Pros: Separation of concerns. Provider developers can onboard faster using the new framework (just the same as the existing framework). Cons: Potential discoverability issues due to being a separate template repository.
At the moment, I personally lean towards 5, potentially paired with 4 later on. Working with different branches in the existing repository might be confusing for those unfamiliar with how to operate across Git branches.
eveld
github-actions[bot]
When creating a new provider using the framework it is nice to be able to start with a boilerplate repository that has the bare minimum for the provider to build and be executed, but that does not implement any functionality.
For other versions of the Terraform Provider SDK there was a similar repository located at: https://github.com/hashicorp/terraform-provider-scaffolding
Right now we only have a learn guide and accompanying repository, but this already has implementation code that would have to be removed for each new provider you make. Having a barebones repository as a starting point and then having the full fledged example (that accompanies the learn guide) to work towards and grab ideas from would be best of both worlds.