amazonka revised to base < 4.19 !

[juhp]

base-4.19.1.0 (changelog) is out of bounds for:

• [ ] amazonka-apigatewaymanagementapi-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-appconfigdata-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-backupstorage-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library - [ ] amazonka-cloudhsm-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-controltower-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-core-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-ec2-instance-connect-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-finspace-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-forecastquery-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-importexport-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-iot-dataplane-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-iotfleethub-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-iotthingsgraph-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-kinesis-video-signaling-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-kinesis-video-webrtc-storage-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: libr ary
• [ ] amazonka-marketplace-analytics-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-marketplace-metering-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-migrationhub-config-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-personalize-runtime-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-rbin-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-s3outposts-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-sagemaker-a2i-runtime-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library
• [ ] amazonka-sagemaker-metrics-2.0 (>=4.12 && < 4.19). Brendan Hay brendan.g.hay@gmail.com @brendanhay. Used by: library

[juhp]

See also brendanhay/amazonka#988

[juhp]

Seems this was an intentional change: apparently only a few amazonka packages are currently in Stackage. Though it seems there may be new releases soon that bring amazonka to 9.8 iiuc.

So I will go ahead and disable them for now.

Thanks to @endgame for quickly responding in the upstream ticket

[endgame]

Just to be clear: I don't think there's a lot of benefit to having only amazonka-core and a few niche service bindings building against GHC 9.8. If I'm wrong, please let me know and I can raise bounds, but it doesn't seem that useful to Stackage.

[juhp]

Okay right makes sense - not sure how they got enabled, but my guess is our commenter mass-bounds tool might have re-enabled them, because "they could be": in that sense just disabling (bounding for) amazonka-core could be enough in future?

[endgame]

I must confess I don't understand the words in your comment. amazonka-*-2.1 (when it eventually happens) should support GHC 9.8 and hopefully beyond.

[juhp]

• We have a tool that automatically disables/enables packages based on dep bounds: I think that is probably how amazon-core and above got re-enabled in Nightly
• Assuming all amazonka-* depend on core, I was suggesting in future you could just set the base upper bound there to handle this kind of thing

[endgame]

Hmm. It is generally but not universally the case that we'd want base bounds to be consistent across amazonka-*. If amazonka itself had not been broken (because its amazonka-sts and amazonka-sso dependencies were unbuildable), and core services had continued to work (e.g., S3, EC2), I wouldn't want to restrict the packages so broadly.