Skip to content

add changelog entry for PR#78 - #79

Merged
pkmandke merged 2 commits into
apple:mainfrom
pkmandke:dev/pr78_changelog
Aug 28, 2026
Merged

add changelog entry for PR#78#79
pkmandke merged 2 commits into
apple:mainfrom
pkmandke:dev/pr78_changelog

Conversation

@pkmandke

@pkmandke pkmandke commented Aug 27, 2026

Copy link
Copy Markdown
Member

#78

Signed-off-by: Prathamesh Mandke <46148373+pkmandke@users.noreply.github.com>
@dengqiaoyu

Copy link
Copy Markdown
Contributor

Does this count as a changelog entry? It seems very specific to an implementation detail that the coreai-opt client does not need to know about.

@crowbat

crowbat commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Does this count as a changelog entry? It seems very specific to an implementation detail that the coreai-opt client does not need to know about.

The result of this change is such that certain models that were previously unpreparable would now be able to be prepared since it wouldn't error out in the final forward pass during preparation. We may want a changelog entry to call that out.

I agree though that the wording of the changelog may make it seem like an implementation detail. Perhaps we make it more user focused by saying

Models using quantizable ops, where no argument to the op is a float dtype tensor with more than one element, can now be prepared with Eager quantizer.

or something of that nature.

@pkmandke

Copy link
Copy Markdown
Member Author

Does this count as a changelog entry? It seems very specific to an implementation detail that the coreai-opt client does not need to know about.

The change definitely needs a changelog entry since it affects prepare for real models in coreai-models. The implementation detail is good to mention for what fixed it, but will make it more clear.

Does this count as a changelog entry? It seems very specific to an implementation detail that the coreai-opt client does not need to know about.

The result of this change is such that certain models that were previously unpreparable would now be able to be prepared since it wouldn't error out in the final forward pass during preparation. We may want a changelog entry to call that out.

I agree though that the wording of the changelog may make it seem like an implementation detail. Perhaps we make it more user focused by saying

Models using quantizable ops, where no argument to the op is a float dtype tensor with more than one element, can now be prepared with Eager quantizer.

or something of that nature.

Makes sense to include details of the impact of the change!

Signed-off-by: Prathamesh Mandke <46148373+pkmandke@users.noreply.github.com>
@pkmandke
pkmandke merged commit a0ddd2e into apple:main Aug 28, 2026
13 checks passed
@pkmandke
pkmandke deleted the dev/pr78_changelog branch August 28, 2026 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants