4 ms·

> the AWS team has implemented it poorly by enforcing it This is whiny and just wrong. Best behavior by default is always the right choice for an SDK. Librarie

> the AWS team has implemented it poorly by enforcing it This is whiny and just wrong. Best behavior by default is always the right choice for an SDK. Libraries/tools/clients/SDKs break backwards compatibility all the time. That's exactly what semver version pinning is for, and that's a fundamental feature of every dependency management system. AWS handled this exactly right IMO. Change was introduced in Python SDK version 1.36.0 which clearly indicatesbreaking API changes, and their changelog also explicitly mentions this new default api-change:``s3``: [``botocore``] This change enhances integrity protections for new SDK requests to S3. S3 SDKs now support the CRC64NVME checksum algorithm, full object checksums for multipart S3 objects, and new default integrity protections for S3 requests. https://github.com/boto/boto3/blob/2e2eac05ba9c67f0ab285efe5050fe0d3eb03bd2/CHANGELOG.rst#L252 https://github.com/boto/boto3/blob/2e2eac05ba9c67f0ab285efe5...

kuschku 2y ago
You mention semver, yet you also show that this API breaking change was introduced in a minor version. Not entirely sure that's how things work?
- r3trohack3r 2y ago
  You're not wrong - the semver doesn't indicate a breaking API change. But, to be fair, this wasn't a breaking API change. Any consumer of this software using it for its intended purpose (S3) didn't need to make any changes to their code when upgrading to this version. As an AWS customer, knowing that when I I upgrade to this version my app will continue working without any changes is exactly what this semver bump communicates to me. I believe calling this a feature release is correct.
  - 0x457 2y ago
    While I agree that the author is just whining about this situation and that AWS did nothing wrong, I'd argue that a change in defaults is a breaking change.
    - dijksterhuis 2y ago
      https://xkcd.com/1172/ https://xkcd.com/1172/
      - 0x457 2y ago
        I don't think that's the case? AWS didn't fix a bug or removed some UB. That's closer changing default key-binding. Anyways, all I'm saying - I would have considered it a breaking change because it changes default behavior.
        dijksterhuis 2y ago
        i treat defaults as a convenience feature which are subject to change :shrug:
        0x457 2y ago
        Correct, I just would appreaciate that change in default behavior would be treated as a breaking change. It's really no that hard to grasp and many OSS projects treat it as such.
hot_gril 2y ago
I want to see the author using GCP. That's where you get actual compatibility breakages.

kuschku 2y ago

You mention semver, yet you also show that this API breaking change was introduced in a minor version. Not entirely sure that's how things work?

r3trohack3r 2y ago
You're not wrong - the semver doesn't indicate a breaking API change. But, to be fair, this wasn't a breaking API change. Any consumer of this software using it for its intended purpose (S3) didn't need to make any changes to their code when upgrading to this version. As an AWS customer, knowing that when I I upgrade to this version my app will continue working without any changes is exactly what this semver bump communicates to me. I believe calling this a feature release is correct.
- 0x457 2y ago
  While I agree that the author is just whining about this situation and that AWS did nothing wrong, I'd argue that a change in defaults is a breaking change.
  - dijksterhuis 2y ago
    https://xkcd.com/1172/ https://xkcd.com/1172/
    - 0x457 2y ago
      I don't think that's the case? AWS didn't fix a bug or removed some UB. That's closer changing default key-binding. Anyways, all I'm saying - I would have considered it a breaking change because it changes default behavior.
      - dijksterhuis 2y ago
        i treat defaults as a convenience feature which are subject to change :shrug:
        0x457 2y ago
        Correct, I just would appreaciate that change in default behavior would be treated as a breaking change. It's really no that hard to grasp and many OSS projects treat it as such.

hot_gril 2y ago

I want to see the author using GCP. That's where you get actual compatibility breakages.