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

unified composition names #3

Open
nimakaviani opened this issue Mar 10, 2022 · 0 comments
Open

unified composition names #3

nimakaviani opened this issue Mar 10, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@nimakaviani
Copy link
Contributor

we have networks.awsblueprints.io/v1alpha1 for aws-provider compositions of VPC:

https://github.com/aws-samples/crossplane-aws-blueprints/blob/9197d704ea8f55621aac4422bd166d6e3c44b583/compositions/aws-provider/vpc/vpc-xrd.yaml#L9-L18

and vpc.awsblueprints.io/v1beta1 for aws-jet-provider compositions of VPC:

https://github.com/aws-samples/crossplane-aws-blueprints/blob/9197d704ea8f55621aac4422bd166d6e3c44b583/compositions/terrajet-aws-provider/vpc/vpc-xrd.yaml#L10-L15

both refer to the same resource but capturing different spec representation of it. does it make sense to settle on something like the following for better naming conventions?

networks.awsblueprints.io/v1alpha1 for aws-provider and
networks.awsblueprints.io/v2alpha1 for aws-jet-provider

or even easier

networks.awsblueprints.io/v1 for aws-provider and
networks.awsblueprints.io/v2 for aws-jet-provider

after all these are samples, so versioning is less relevant. but naming inconsistencies could be confusing. thoughts?

@vara-bonthu vara-bonthu self-assigned this Mar 10, 2022
@vara-bonthu vara-bonthu added the enhancement New feature or request label Mar 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: To do
Development

No branches or pull requests

2 participants