according to semver, every 0.0.x release is supposed to be considered "breaking".

we could even do 0.1.x, but I think this is something we should get feedback from long before 1.0, not afterwards.

That's fair - I just don't want to get in the habit of regularly breaking people's Terraform configs. My other hesitance is that this becomes annoying for the majority of single organization deployments. (Maybe a multi-org use-case ends up having multiple Terraform configs too, it's not unreasonable for different template admins to handle their IaC independently? Can't say for sure)

I feel like we could make the experience 'safer' without sacrificing any of the convenience of the default. What would be your thoughts on keeping thedefault_organization_id attribute on the provider optional, but returning a custom error if both it, and the organization id on the resource, weren't supplied? That way there'd be no implicit org selection.

• Allowing them to set a global default adds a lot of complexity to the provider
• It reduces our ability to validate the config during a plan (becauseorganization_id would have to be optional on every resource that takes one)
• It's really not that hard for them to just add...

data"coderd_organization""default" {is_default=true}resource"...""..." {organization_id=coderd_organization.default}

It's a tiny bit of extra code for them, but avoids a lot of complexity, confusion, and magic for everyone.

I don't really agree that it adds a huge amount of complexity to the provider, user-facing or implementation wise, but I agree, it would be incredibly annoying forterraform plan to not pick up that you haven't set an org ID in either place. I've decided the implicit org selection (the first the user is a member of) is pretty bad, so yeah, let's just get rid of it for now, and then we can include it in the next release, where we're already bumping the minor version.