Update CHANGELOG.md

[kameyer226]

Do we bump up to 2023.6.1 and make changes as such or are we OK with what we currently have?

[ddkohler]

Do we bump up to 2023.6.1 and make changes as such or are we OK with what we currently have?

@kameyer226 after more inspection, I believe the answer is that you want to:

• Keep all versions at 2023.6.0. yaqd-core and yaqd-fakes were not technically released, even though their version.py file was updated. e.g. there is currently no yaqd-core v2023.6.0 on pypi.org.
• After this MR goes through, create release tags for both yaqd-core and yaqd-fakes (confer previous releases to see how this is done). I believe this is the step that formally releases our code as a new version.

@ksunden @untzag this is a little unfamiliar to me because I am used to having only one package in a repository. Let me know if I got this wrong.

[ksunden]

Seems correct, the tags are prefixed with the subproject

They are grouped into one repo because their tests are pretty inextricable from one another, but each can have their own release cycle if they do not incur cross correlated changes. (And if we do wish to release two or three at once, we actually need to tag the same commit multiple times with the different prefixes to get the CI to upload)

I had not prepped yaqd-core/fakes for release because there were inflight planned changes when I swapped from flit to hatch in #59

If there were not such changes pending, I probably would have prepped and done a release immediately to exercise the release mechanisms even without functional changes (though I did prove that they worked with yaqc first, so not too worried)