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

Create a new release #340

Closed
LegNeato opened this issue Apr 8, 2019 · 14 comments
Closed

Create a new release #340

LegNeato opened this issue Apr 8, 2019 · 14 comments
Assignees

Comments

@LegNeato
Copy link
Member

LegNeato commented Apr 8, 2019

It's about time to push out a new release. I want to automate a bit more of the process as well.

We probably need the book updating working too.

@theduke
Copy link
Member

theduke commented Apr 8, 2019

We have some breaking changes merged into master but I think they are so small that they don't really merit a version bump yet.

We should probably cherry-pick the non-breaking stuff into a 0.11 branch and release from there.

@theduke
Copy link
Member

theduke commented Apr 8, 2019

Well, actually, #312 is really minor and ScalarValue is still there, only deprecated, so I think master should be fine.

@LegNeato
Copy link
Member Author

I landed changes to release automation. I think we want #353 and then we can do a release. We should do a minor (not patch) version bump as we increased the minimum rust version.

@LegNeato LegNeato self-assigned this May 12, 2019
@theduke
Copy link
Member

theduke commented May 12, 2019

If we are doing a minor now we should also include #333 since it provide a significant usability improvement. The syn version bump also requires a minor version.

That does bump rust requirement to 1.34, but only if you use certain attributes on field resolvers with the new impl_object. Considering the big improvement I think it's worth it.

That way we won't need another minor bump until async support.
Better one dependency bump than two in a relatively short time.

@LegNeato
Copy link
Member Author

Hmmm, that is a huge change. I'd prefer to do a release with current state and then land that, have it sit in master for a bit, and then cut another one.

@theduke
Copy link
Member

theduke commented May 12, 2019

It's a big change but not a user visible one right away since everyone will still be on the old macro. Also I've converted one large and two smallish projects and all works fine.

It wouldn't see much testing on master anyway.

@LegNeato
Copy link
Member Author

I don't think we need to wait on the book here. Do you want to run a release or shall I?

@theduke
Copy link
Member

theduke commented May 16, 2019

Can do, but since you did all the work on the releasing tool, you should have the honors of breaking it in.

@theduke
Copy link
Member

theduke commented May 16, 2019

@LegNeato actually I'd love to get #355 in as well since it's breaking.

@LegNeato
Copy link
Member Author

Ok, I'll do a release later tonight! Probably best for me to do it so if automation breaks I can fix it

@theduke
Copy link
Member

theduke commented May 16, 2019

@LegNeato please also check Gitter, I sent you a message with a nice surprise.

@LegNeato
Copy link
Member Author

Juniper 0.12.0 is out!

Automation seemed to work well. cargo-release is pretty brittle, so I added some additional directions to RELEASING.md suggesting a clean checkout.

@theduke
Copy link
Member

theduke commented May 17, 2019

@LegNeato for future reference, what was brittle about it?

@LegNeato
Copy link
Member Author

The cargo-release parts error out when pushing to git if your repo's git remote branch isn't in sync with upstream/master.

A clean clone with this repo as origin makes all those issues impossible, so that's what I added to the docs.

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

No branches or pull requests

2 participants