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

Publish new version #120

Closed
joehoyle opened this issue Feb 14, 2019 · 10 comments
Closed

Publish new version #120

joehoyle opened this issue Feb 14, 2019 · 10 comments
Assignees

Comments

@joehoyle
Copy link
Member

Is there a reason we haven't had a release in over 9 months? From what I gather hm-linter is still running 0.5.0 which is pretty annoying because we are missing PRs that have been merged way after that.

I assume we just need to tag the release, and then upload it to S3 for hm-linter?

@mikeselander
Copy link
Contributor

We have ~ 10 PRs ready for final review that need to get in for an 0.6.0 release which is what we're waiting for, I believe.

@joehoyle
Copy link
Member Author

Are those required for 0.6.0?

@mikeselander
Copy link
Contributor

I would argue that the release doesn't do much of anything without them. We've been waiting for a release for so long that not including these changes would be a bit silly.

I would argue that we need the following (at a minimum) for an 0.6.0 to make sense:
#82, #101, #114, #81, and #88 if anyone can figure out what in the sam hell is going on with those tests.

Really, they all look to be in really good shape (except for #88), we're just waiting on final sign off. Since these are core guiding rules on how we code we've been waiting in @rmccue to give final sign off. I'm more than happy to start merging things but didn't want to go crazy without your or Ryan's eyes.

@mikeselander
Copy link
Contributor

On that topic, it would be nice for us to know who needs to sign off on these changes before they get merged. There's a few of us that are more than willing to write and review the work but, since we don't want to be making changes without your knowledge, we've been holding off from merging beyond stylelint changes.

Perhaps if we could get a quorum of Senior Engineers (or perhaps soon Principal Engineers) to sign off than we can just merge?

@joehoyle
Copy link
Member Author

I would argue that the release doesn't do much of anything without them. We've been waiting for a release for so long that not including these changes would be a bit silly.

I think this is the logic that probably get us here too! Doing a release shouldn't be difficult, so I don't know why we can't just do two. I know you might be waiting for those issues, because they are important. On the other hand, I've been waiting for 4 months to get #96 finally shipped, as that one is driving me crazy!

I feel like we are already way overdue with a release, and we should do that. I'm fine with a release in another week if all those other issues will be merged by then. I'd review them but there's no way I have chance to get them to at least pre-retreat.

@mikeselander
Copy link
Contributor

mikeselander commented Feb 15, 2019

I think this is the logic that probably get us here too!

What got us here is having a bottleneck on approvals and Ryan not having time to get to these PRs. We could have had a solid release as far back as Sep/Oct if we'd just gotten existing work merged.

Doing a release shouldn't be difficult, so I don't know why we can't just do two.

There will just only really be two changes in it, but sure ¯\_(ツ)_/¯. The only other thing besides your two PRs is Stylelint, but that should really be pulled from NPM once we get it published.

I'm not trying to block this, I've just been running on the assumption that if we're going to put work into this repo we should put that effort into getting the work that's already been completed merged as a priority since we have both clients and developers are screaming for these changes. I totally understand why you'd want to just get your changes in now 👍

@rmccue
Copy link
Member

rmccue commented Feb 15, 2019

On that topic, it would be nice for us to know who needs to sign off on these changes before they get merged. There's a few of us that are more than willing to write and review the work but, since we don't want to be making changes without your knowledge, we've been holding off from merging beyond stylelint changes.

Anything that's uncontroversial is fine. The biggest things to consider are regressions and usability. Publishing regressions is super painful, and it means we have to have .1, .2, .3 releases basically immediately, so if we can catch those ahead of time, it's much better. (Mainly this is from phpcs/wpcs/eslint updates.) Additionally, when we publish the standards, they need to be usable.

Main thing that was blocking this really was that hm-linter had a bug where it wasn't using the right standards version, so publishing a new version would have lead to inconsistent stuff. That should be mostly fixed now.

Anyway, totally my bad here. I will try to get reviews done more promptly in the future.

@mikeselander mikeselander self-assigned this Mar 29, 2019
@kevinlangleyjr
Copy link
Contributor

@rmccue do you think with the latest changes we've had reviewed and merged here, that we could possibly release 0.6.0 shortly?

@rmccue
Copy link
Member

rmccue commented Apr 2, 2019

@mikeselander is working on getting this released, I think the plan was this week or next.

@mikeselander
Copy link
Contributor

The new version has been published 🙌

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

4 participants