search

yola / healthcheck

Classes, which help Yola service to implement health checks for themselves
MIT License
0 stars 0 forks source link

Bump version to 0.0.7 for release #19

Closed alexmojaki closed 9 years ago

alexmojaki commented 9 years ago

In general do I need approval to merge such requests?

snitch commented 9 years ago

:sparkles: No lint errors found. :sparkles:

stormf commented 9 years ago

You should add a changelog entry to describe what's contained in this release.

Generally the only approval you need is a :+1: from someone at yola.

snitch commented 9 years ago

:sparkles: No lint errors found. :sparkles:

alexmojaki commented 9 years ago

@jouberthenk :+1: ?

stormf commented 9 years ago

:+1:

So usually you don't need to @mention specific people to review your stuff unless you need their expertise. As long as the project is linted (has a .lintrc), snitch will chime in with warnings or :sparkles: which means participants will get a notification that something has changed in the pull and they can look again. If you feel something is being ignored for too long (or if the project doesn't have snitch), you can leave comment with :bell: in it to re notify participants.

stormf commented 9 years ago

also add a tag https://github.com/yola/healthcheck/tags

alexmojaki commented 9 years ago

I don't know how

adrianmoisey commented 9 years ago

https://github.com/yola/healthcheck/releases -> Draft a new release

alexmojaki commented 9 years ago

Am I supposed to give it an actual title or attach files?

stormf commented 9 years ago

You could model it on the last release: https://github.com/yola/healthcheck/releases/tag/0.0.4

adrianmoisey commented 9 years ago

^^^ what Henk said. No worries about any attached file.

alexmojaki commented 9 years ago

But I can't actually tell if the big 0.0.4 is a title or just generated from the tag version.

adrianmoisey commented 9 years ago

I think it's the title

alexmojaki commented 9 years ago

And I wasn't sure if github attached those files or a person, although I guess @adrianmoisey covered that.

adrianmoisey commented 9 years ago

See https://github.com/yola/yoaudit/releases

alexmojaki commented 9 years ago

It's a really great title

adrianmoisey commented 9 years ago

Literally the best

stefanor commented 9 years ago

In general do I need approval to merge such requests?

What's the point of a pull request, if nobody is going to review it. So, yes, if you're opening a pull request, it's so that you can get review.

https://github.com/yola/healthcheck/releases -> Draft a new release

or just tag with git tag, and push the tag with a push --tags

adrianmoisey commented 9 years ago

What's the point of a pull request, if nobody is going to review it. So, yes, if you're opening a pull request, it's so that you can get review.

Unless it's a PR from master into release

alexmojaki commented 9 years ago

@stefanor my understanding from the Git Etiquette page was that everything must be done in a pull request, never a push to master, but that in some cases (e.g. the master -> release example that Adrian gave) it's just to leave a paper trail. That's why I was checking.

stefanor commented 9 years ago

That's the only "some case" I can think of.

We used to also do library releases (like this PR) without a PR, as there wasn't much to review. (And a whole bunch of release-related stuff has to be done by hand, without review, anyway. And GitHub had no UI for creating tags). But that's pretty frowned on these days...