Open RustyNova016 opened 6 months ago
Would rather not merge this, the history isn't linear. Is it intended for #24 to supersede this PR?
I agree, seems like a duplicate of #24 but including the added docs?
I agree, seems like a duplicate of #24 but including the added docs?
You asked on #20 to separate the docs, so I separated them. #24 can be merged now, but #22 is meant to be for the documentation update.
Should I had waited for #24 to go through?
I agree, seems like a duplicate of #24 but including the added docs?
You asked on #20 to separate the docs, so I separated them. #24 can be merged now, but #22 is meant to be for the documentation update.
Should I had waited for #24 to go through?
No that's fine, we can merge this one later 😄
We can merge this once the other PR goes through, but the duplicate commit history should be double-checked before merging.
This one not only need to wait #24 but also work on the whole documentation update like discussed in #20. Unless another branch get created for the documentation, but that would either mean going before or after #25, or else we would have to move the new documentation to the new files.
I feel like this PR has become more of a reminder of that there is work to put somewhere at one point than actually mergable.
You can remove the unused commits in a rebase, and once #24 is merged, rebase main
onto this branch, and push. I can see how the commits ended up this way here, but it does - and can - mess up history.
After approval from @InputUsername (ref: #27), I've rebased this branch against main, squashed the commits, and fixed my nitpick. This is just so we can get this great PR into main.
@InputUsername We're all good to merge now.
cc: @RustyNova016 - you'll need to do git pull --rebase
.
Looks good.
@shymega should we wait until after 0.8.0 is released so we can add docs to everything in one go (e.g. for 0.8.1)?
Wait for v0.8.1. Sorry, didn't see your ping.
The current response models lack any MBID mapping information that would appear on the request, making it impossible to determine if the listen is mapped or not.
I've added the missing fields, and added documentation comments for all the other fields of the response.