ESD-25205: Deprecate enabled_clients on the auth0_connection resource

[sergiught]

🔧 Changes

The issue surfaced through #416 is caused by the fact that we allow for 2 ways of managing enabled_clients on 2 separate resources that affect the planning phase of the terraform process.

This is similar to what we experienced when we had the auth0_organization.connections and auth0_organization_connection resource, where we ended up keeping just the latter.

So we're deprecating the use of enabled_clients through the auth0_connection resource in favor of the auth0_connection_client resource.

📚 References

🔬 Testing

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)

[codecov-commenter]

Codecov Report

Base: 86.80% // Head: 86.80% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (17d8077) compared to base (3ca221f).
Patch has no changes to coverable lines.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #421      +/-   ##
==========================================
- Coverage   86.80%   86.80%   -0.01%     
==========================================
  Files          41       41              
  Lines        9040     9038       -2     
==========================================
- Hits         7847     7845       -2     
  Misses        924      924              
  Partials      269      269              

Impacted Files	Coverage Δ
internal/provider/resource_auth0_connection.go	72.83% <ø> (-0.17%)	⬇️
internal/provider/structure_auth0_connection.go	90.42% <ø> (-0.01%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[willvedd]

**Update: ** Instead of deprecating, we're just opting to remove the problematic field altogether. Either way users will need to migrate to the resource, a breaking change just communicates that in a stronger way than deprecation. Once we've graduated from v0 we'll be more methodical about deprecations and maintaining backwards compatibility.

[willvedd]

Sergiu and I looked at this together, we've decided to remove the deprecation label and instead just remove the functionality outright. It'll make for a quicker migration for all involved IMO.

[perplexa]

it would be nice to have some deprecation notice next time for people who are using this provider in production environments.

[maxime-gaudron]

@willvedd When will the provider reach v1 tho? it wasn't a great surprise this morning :)

[roblframpton]

Does this repo not use semantic versioning? This breaking change caused us some difficulty when our CI started failing due to the interface change but our local workspaces were fine, and we'd like to avoid that in the future.

[sergiught]

Hey @roblframpton 👋🏻

Thanks for taking the time to express this painpoint. We understand how crucial stability and predictability are in software development, and we regret any disruptions you experienced.

To clarify the situation, up until now, we have been operating on version v0 of the provider, and during v0, we are not strictly bound by semver rules. The v0 indicates that our API is not yet considered stable and as a result, we might introduce breaking changes without following semver convetions.

However, we want to assure you that we have been closely monitoring the feedback from users like you, and we recognize the importance of adhering to industry standard versioning practices for better compatibility and predictability moving forward. So because of this we are excited to announce that we have recently released the v1.0.0-beta.0 and from the moment we launch the GA version v1.0.0 on we are committed to strictly adhering to semantic versioning principles. We encourage you to try out this new version and start planning your migration to v1.0.0. Please rest assured that moving forward, we will ensure compatibility and gradual updates in line with semver guidelines.

If you encounter any issues or have any questions during the migration process, we are more than willing to provide assitance and support to smoothen the transition.

Thanks for your understanding and continued support!

---

📚 Resources

Quickstart | Documentation | Migration Guide | Changelog