Breaking changes for core services & enterprise acceptance

[peterpicard]

❓ General Issue

The Question

First, I would like to say that I am a big fan of the development work everyone is doing on this project. A big thumbs up!

I work in a large enterprise environment and consult multiple external customers. I would love to use the CDK for all AWS infra management, but am concerned with the frequency of breaking changes for core service constructs (RDS in v0.15.0 for example). It's been quite a few months since it went GA.

Is there a roadmap for when the CDK will be in a state where enterprise operation teams can adopt it and count on the fact that the CDK code written last year will still work in a DR scenario this year, without needing to be locked to old/outdated CDK versions?

Thanks for your time and answer.

Environment

• CDK CLI Version: 1.16.1 (build 9a5a761)
• Module Version: RDS
• OS: all
• Language: Python

Other information

Suggestions:

• breaking changes for core service constructs (RDS, EC2, etc) should be bundled into major version upgrades and not minor ones, as was the case for v0.15.0
• introduce stable/enterprise branches similar to what Redhat is doing with RHEL/Fedora
• introduce a migration tool to help automate the refactoring of CDK code to be compatible with the latest CDK version (i.e. automatically fix issues for RDS code when moving from v0.14.0 -> v0.15.0)

[thesurlydev]

I've often wondered about the versioning choice myself. It seems there are breaking changes with almost every new release yet only the minor version changes. An assumption could be made that semantic versioning is used but as soon as someone sees breaking changes while not changing major version, I'm sure it causes confusion.

While I was very excited about this project and began recommending to teams in my org, this combination of weird versioning and continually breaking changes has made me reconsider. Breaking changes are fine but please come up with a better solution than you have now for communicating and segregating them in a way that doesn't cause confusion.

[ccfife]

Here is an issue in the aws-cdk-rfcs repo where we are discussing how to address this problem. Feel free to chime in with your feedback there. aws/aws-cdk-rfcs#116

[eladb]

Closing in favor of aws/aws-cdk-rfcs#116