Skip to content

Conversation

@alexfmpe
Copy link
Contributor

@alexfmpe alexfmpe commented Jun 28, 2024

Probably best to merge #95 first
On top of #95

@ProofOfKeags
Copy link
Collaborator

Can you rebase this on #95

@alexfmpe
Copy link
Contributor Author

alexfmpe commented Jun 29, 2024

I actually had to work on this on top of #95 otherwise it wouldn't build for me, but decided to split it out to make independent PRs so it could be merged before the other one given the diff is easier to review (though possibly harder to replicate the testing I did for each successive bound bump where as the other one only needs two cases - before and after 5.2).

I don't have a preference myself in this case, is chaining the PRs preferable here?

@ProofOfKeags
Copy link
Collaborator

I don't mind chaining PRs personally. In principle I'm interested in merging both of these but I wanted to verify the build worked for me and from what I remember one of them doesn't build without the other. If you could make a single PR with two diff commits the review will be both easy to review in chunks and still capture the proper dependency order.

@alexfmpe
Copy link
Contributor Author

alexfmpe commented Jul 2, 2024

one of them doesn't build without the other
still capture the proper dependency order.

More specifically, this repo may or not build out of the box depending on which package snapshot one's build tool is looking at. If http2 <5.2 is used, the repo can build and so can this PR.

At any rate, I rebased #95 in here to make it unconditionally build since it's accidentally a dependency when using an up-to-date snapshot, unless one's package's constraints prevent newer http2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants