## 2024-03-06

   1. Terraform variable/block Alias
   - For https://github.com/opentofu/opentofu/issues/1156 we realized we had not formalized what we will eventually alias `terraform` to as we move forward.  This covers the `terraform {}` block as well as the `terraform.workspace` and `terraform.env` config variables
      - During the community discussion on the Pull Request, the discussion revolved around using `tofu` as the alias or `meta` as the alias.
      - `tofu` fits with the current “theme” of the block and alias.
      - `meta` is more tool agnostic and may be a better long term / community option.
      - We’ve already accepted the addition of a tofu-specific namespace for this, and we’re just deciding which alias fits best
      - Note: This has an open PR by an external contributor and is blocking them: https://github.com/opentofu/opentofu/pull/1305
   - Other patterns to consider where the word “terraform” shows up:
      - `terraform.tfvars`: https://developer.hashicorp.com/terraform/language/values/variables
      - `.terraformrc`: https://developer.hashicorp.com/terraform/cli/config/config-file
      - There may be others…
      - The ones above we’d probably alias to `tofu` at some point
   - Decision:
      - Generally -  `tofu`
      - But then - this brings up an older discussion/decision made that the RFC to submit such “breaking” change in the language would require certain tooling (such, language server support for IDEs etc)
      - ***Before moving forward*** - we probably need an RFC for OpenTofu Language Server Protocol
      - Before introducing any language features or syntactic changes that diverge from Terraform language we should introduce some sort of file or other system to help language services distinguish between the two
         - Supporting tooling may break
         - E.g., tflint, IDE, etc
         - Creates a crappy experience for users
      - We should be extra careful with changes to the api of modules - having different file extension may affect the way they reference one another
         - E.g., A `.tf` file with `module "foo"` and a `.otf` file with `module "foo"`. What happens if something needs to reference `module.foo`? Which module gets used? How do language servers / IDEs check this stuff? How do module authors ensure compatibility.
         - So it’s mostly about the cross-references that touch module outputs.

      <aside>
      💡 We use the term “breaking change” here, but we don’t really mean the change is breaking. These are all opt-in features. But what we mean is that the experience may be poor: e.g., tflint/tfsec/etc will fail, IDEs won’t do syntax highlighting, etc.

      </aside>

      - Proposal 1: before moving on with any of the breaking changes RFC - we should choose and start to implement a solution that would allow those to coexist in IDEs/module authors and all the concerns listed above ?
         - Against: (everyone)
      - ✅ **[DECISION]** Proposal 1a: allow 1.7 to go out with state encryption as a breaking change, but block future breaking changes until we land this RFC in 1.8.
         - In favor: Roni, Jim, Igor, Roger, Marcin—**but with the caveat:**
               - If this is going to take more than ~1 quarter to implement, we should rethink it.
               - So we need to know: if we get someone working on this ASAP, is it likely that we can get this RFC approved, implemented, and included in 1.8?
               - If yes, let’s do it.
               - If no, let’s reconsider.
      - Proposal 2: maintain Tofu 1.6 LTS for a long period of time and always have it there as a backward compatible way to transition from Terraform. So you switch to that first, and then if happy in the Tofu world, then we have upgrade guides from Tofu 1.6 to newer versions, and those newer versions may have breaking changes.
         - In favor: Igor
      - Proposal 3: we ask for an initial placeholder RFC, but we don’t block releases with breaking changes on the RFC being completed/implemented. Instead, when we launch breaking changes, we have something that says “this is a breaking change, if you want to use it in a way compatible with Terraform, see this RFC, which will let you do that in a  future version.” And eventually, that RFC does land, and we have what we need without blocking.
         - In favor: Roger, Marcin, Igor


