feat(contributors): use 0.0.0 as a version marker #6463
Conversation
Replace `999.0.0` with `0.0.0` to reduce the risk in accidental publishing. If, by accident, we will publish a module with the version `999.0.0`, it will semantically always be the latest version, and that’s catastrophic. By using `0.0.0` we reduce this risk. Worse case we will have a `0.0.0` module published, which is not a huge problem. Codify this in `scripts/get-version-marker` and reuse everywhere. We also improved the `pack.sh` script in the following ways: - Use `get-version.js` to obtain the version for build.json (instead of reading from lerna.json) - Fail if the version does not start with “1.” to protect against publishing a different major version - Adds an additional check to verifies that none of the file names under `dist/` uses the “0.0.0” marker.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There was a problem hiding this comment.
I very much prefer 0.0.0.
I also wonder if we should add provisions on cdk --version and error messages that include the chain's version (CX protocol mismatch, ...) so they actually display something other than 0.0.0, for example HEAD or local development build, something like that... That's not essential, but I feel like it may save some confusion to contributors who don't expect this (it should also be mentioned in CONTRIBUTING.md that non-release builds will always consistently use version 0.0.0 internally).
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
eladb
changed the title
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
…ld be the repo-wide version
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Stack-level tags apply to all supported resources in a stack. If they change, a fast "no-op" deploy should not occur (e.g. a tag with the CDK version or a tag with the commit hash when running in CI). Fix the `'deploy not skipped if template changed'` test that was including the `force` option. Fix CLI integ tests not working anymore after aws#6463 and the `0.0.0` version.
* fix(cli): fast "no-op" deploys do not consider tags Stack-level tags apply to all supported resources in a stack. If they change, a fast "no-op" deploy should not occur (e.g. a tag with the CDK version or a tag with the commit hash when running in CI). Fix the `'deploy not skipped if template changed'` test that was including the `force` option. Fix CLI integ tests not working anymore after #6463 and the `0.0.0` version. * else * compareTags * README Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Please see updates in CONTRIBUTING for details on new versioning schema in this repository.
Replace
999.0.0with0.0.0to reduce the risk in accidental publishing. If, by accident, we will publish a module with the version999.0.0, it will semantically always be the latest version, and that’s catastrophic. By using0.0.0we reduce this risk. Worse case we will have a0.0.0module published, which is not a huge problem.Codify this in
scripts/get-version-markerand reuse everywhere, includingpkglint.We also improved the
pack.shscript in the following ways:get-version.jsto obtain the version for build.json (instead of reading from lerna.json)dist/uses the “0.0.0” marker.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license