Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.92%. Comparing base (7717c29) to head (859c343).

@@            Coverage Diff             @@
##             main    #4883      +/-   ##
==========================================
- Coverage   92.36%   91.92%   -0.44%     
==========================================
  Files         488      488              
  Lines       41603    41603              
  Branches     5409     5372      -37     
==========================================
- Hits        38425    38245     -180     
- Misses       3122     3300     +178     
- Partials       56       58       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I feel like the following might've justified having a @std/uuid@0.224.3 release:

• deprecation(uuid): deprecate v1.generate() signature with buf and offset
  parameters (deprecation(uuid): deprecate v1.generate() signature with buf and offset parameters #4880)
• deprecation(uuid): rename V1Options to GenerateOptions (deprecation(uuid): rename V1Options to GenerateOptions #4872)
• fix(uuid): validate namespace UUIDs in v3.generate() and v5.generate()
  (fix(uuid): validate namespace UUIDs in v3.generate() and v5.generate() #4874) (breaking fix)

Maybe nothing we can do now, but how can we do this better next time?

I feel like the following might've justified having a @std/uuid@0.224.3 release:

What do you mean? @std/uuid@0.224.3 has been released in this release

Sorry, I mean't 0.225.0.

This is intentional because deprecation doesn't break things unlike BREAKING

Is it fine to include deprecations and breaking fixes in patch releases?

deprecation is fine because it basically only changes docs (the user get 'deprecated' message, but the code itself doesn't break)

breaking fixes

I don't think 'breaking fix' is an official term (at least there's no commit tag expressing it).

Ok. The reason for including deprecations makes sense.

Your reasoning for including breaking fixes doesn't make sense to me. But on second thought, including them in a patch release is fine because they only break incorrect use of the API, which seems fine to do in a patch release.