endgame
commented
1 year ago We should probably do this for any amazonka-*-0.0.0:
amazonka-autoscaling
amazonka-cloudformation
amazonka-cloudfront
amazonka-cloudsearch
amazonka-cloudsearch-domains
amazonka-cloudtrail
amazonka-cloudwatch
amazonka-cloudwatch-logs
amazonka-codedeploy
amazonka-cognito-identity
amazonka-cognito-sync
amazonka-config
amazonka-datapipeline
amazonka-directconnect
amazonka-dynamodb
amazonka-ec2
amazonka-elasticache
amazonka-elasticbeanstalk
amazonka-elastictranscoder
amazonka-elb
amazonka-emr
amazonka-iam
amazonka-importexport
amazonka-kinesis
amazonka-kms
amazonka-lambda
amazonka-opsworks
amazonka-rds
amazonka-redshift
amazonka-route53
amazonka-route53-domains
amazonka-s3
amazonka-sdb
amazonka-ses
amazonka-sns
amazonka-sqs
amazonka-storagegateway
amazonka-sts
amazonka-support
amazonka-swf@brendanhay If you're happy for me to do so, I can use Hackage Trustee powers to go through and add amazonka-core <0.0.1 bounds over all these packages.
brendanhay
When creating the subdir list for source-repository-package, I noticed that if you leave out amazonka-s3, it might pick one from hackage. The solver could pick amazonka-s3-0.0.0 since it has really lax bounds. This will cause a confusing error message, since the user might not know they forgot this subdir.
Could we tighten the bounds of amazonka-s3-0.0.0 on hackage to prevent it from getting chosen so easily?