Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the word developer preview from your official site #583

Closed
prabhu opened this issue Aug 16, 2018 · 3 comments
Closed

Remove the word developer preview from your official site #583

prabhu opened this issue Aug 16, 2018 · 3 comments

Comments

@prabhu
Copy link

prabhu commented Aug 16, 2018

I have been using CDK for sometime now and its been absolutely great. I was able to setup mocha based unit tests and code coverage for each line of cloud code for the first time in a while now so I have nothing but praises for CDK.

Unfortunately, some security folks in my organisation are making a big fuss about the word developer preview. tbh, given the version 0.8.1 and the amount of activity in this repo this is hardly a developer preview. Can you consider removing that and replacing it with beta or coming soon or some such?

@eladb
Copy link
Contributor

eladb commented Aug 16, 2018

Our official recommendation is not to use the CDK for production until it is in 1.0.

"Developer preview" essentially means that we cannot commit to the stability of the APIs. There could be fundamental changes before we release 1.0, and this is the message we wish to convey when we use this term. This means you should use this "at your own risk" because our ability to provide support is very limited as we prioritize quick progression over stability before 1.0.

We take security very seriously, even during a developer preview. But again, since things are moving fast, and we still have many areas of the framework that haven't reached the quality bars that we expect, it's hard for us to provide assurances. Specifically, we have a few major features that should help users get a good picture and have more control over security-related changes that may happen in their stack due to new dependency versions, etc (see #286 as an example).

An approach some users are taking is to check-in their synthesized templates into source control and make sure to code-review any changes to the actual CFN templates as part of a normal code review process. This can help reduce the chance for unexpected changes.

Also, curious about your testing - can you share some code? (maybe on another thread)

@RomainMuller
Copy link
Contributor

I second @eladb's request to see the tests you wrote, if it is possible for you to share :)

@rix0rrr
Copy link
Contributor

rix0rrr commented Sep 17, 2018

Assuming resolved. Reopen if you still have issues.

@rix0rrr rix0rrr closed this as completed Sep 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants