Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: v0.2.0-beta.1 #716

Merged
merged 1 commit into from
Aug 11, 2021
Merged

release: v0.2.0-beta.1 #716

merged 1 commit into from
Aug 11, 2021

Conversation

EverlastingBugstopper
Copy link
Contributor

@EverlastingBugstopper EverlastingBugstopper commented Aug 5, 2021

🐛 Fixes

  • Update GraphQL types to match new API Schema - EverlastingBugstopper, issue/696 pull/697

    The Apollo Studio API introduced a change that made a field in the subgraph publish mutation nullable. This caused our codegen to fail and users started getting some cryptic error messages for failed publishes in older versions of Rover.

    This release handles these cases better and also introduces local tooling for building old versions of Rover with the API schemas that were in production at the time that version was published with cargo xtask dist --release vx.x.x.

📚 Documentation

  • Fix broken link to supergraph schemas - abernix, issue/687 pull/706

    There was a broken link in our docs that now points to a set of definitions of supergraphs and subgraphs that lives in the docs for Federation.

@EverlastingBugstopper EverlastingBugstopper added this to the v0.2.0 milestone Aug 5, 2021
@EverlastingBugstopper
Copy link
Contributor Author

This release job "failed" because I hard coded the release number when I was testing and never fixed it - the release was actually successful and I've since updated the release to include the schema

@EverlastingBugstopper
Copy link
Contributor Author

@abernix we released v0.1.10 with a patch and v0.2.0-beta.1 with the same patch - how would you recommend moving these two separate PRs forward? Should I only merge this one and just close the v0.1.10 PR? That could then be branched off of in the future if we ever needed to patch v0.1 again, and v0.2 would live on main.

Only problem with that is that then the changelog on main won't have v0.1.10 info... Perhaps an alternative is to revert the revert on the v0.1.10 release branch and then just not do the squash and merge strategy?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚢 release release PRs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant