6 ms·

Initially we strive for 100% interoperability. The provider framework has been kept MPL, as have the providers, so we will keep being compatible. We will see

Initially we strive for 100% interoperability. The provider framework has been kept MPL, as have the providers, so we will keep being compatible. We will see what the longer-term future brings, and we'll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it's in place. Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.

jen20 3y ago
> currently temporary Technical Lead of the OpenTF Project Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).
- ahl 3y ago
  I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.
  - jen20 3y ago
    I doubt that "clean room" fixes for each new commit in Terraform can be authored in order to maintain compatibility with the canonical source.
- fishnchips 3y ago
  I pity anyone who underestimates Kuba. OK, most people I've worked with in tech are probably smarter than me, but this guy plays in a different league.
maccard 3y ago
Do you have an idea on where you stand on incompatible changes that are strict improvements over TF? As a concrete example, https://github.com/hashicorp/terraform/issues/13022 https://github.com/hashicorp/terraform/issues/13022 - My only read on this is that Hashicorp arent doing this as this removes a key selling point of Terraform Cloud.
- cube2222 3y ago
  We're planning to stay 100% backwards compatible, and in the early stages we definitely want for it to be easy for people to migrate back and forth between both tools - even have teams with different engineers using different tools. DSL changes are honestly the thing we'd like to limit the most, but as long as they're backwards compatible, the RFC process will welcome them, and they will be discussed and considered! The important thing is for features to be opt-in. You should be able to limit yourself to a feature-set that is Terraform-compatible, if you want. If you want to use additional features on top of that, then that will be an option as well - we definitely want to innovate.
  - maccard 3y ago
    Thanks. I guess that's a little disappointing on one hand, but on the other makes perfect sense! FWIW, we're excited to see TF develop again

jen20 3y ago

> currently temporary Technical Lead of the OpenTF Project Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).

ahl 3y ago
I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.
- jen20 3y ago
  I doubt that "clean room" fixes for each new commit in Terraform can be authored in order to maintain compatibility with the canonical source.
fishnchips 3y ago
I pity anyone who underestimates Kuba. OK, most people I've worked with in tech are probably smarter than me, but this guy plays in a different league.

maccard 3y ago

Do you have an idea on where you stand on incompatible changes that are strict improvements over TF? As a concrete example, https://github.com/hashicorp/terraform/issues/13022 https://github.com/hashicorp/terraform/issues/13022 - My only read on this is that Hashicorp arent doing this as this removes a key selling point of Terraform Cloud.

cube2222 3y ago
We're planning to stay 100% backwards compatible, and in the early stages we definitely want for it to be easy for people to migrate back and forth between both tools - even have teams with different engineers using different tools. DSL changes are honestly the thing we'd like to limit the most, but as long as they're backwards compatible, the RFC process will welcome them, and they will be discussed and considered! The important thing is for features to be opt-in. You should be able to limit yourself to a feature-set that is Terraform-compatible, if you want. If you want to use additional features on top of that, then that will be an option as well - we definitely want to innovate.
- maccard 3y ago
  Thanks. I guess that's a little disappointing on one hand, but on the other makes perfect sense! FWIW, we're excited to see TF develop again