emmetogrady

Hi HN!

In my work as a PHP developer I sometimes get frustrated when I or a teammate gets the "release version" wrong of a library that we use, and a backwards incompatible change gets released under a "minor" or "patch" version bump. This usually causes breaks for the unlucky person who updates the dependencies when, if everybody stuck to true semantic versioning, everything should work exactly as it did before.

I'm working on this proof of concept to help; it analyses proposed changes in a GitHub pull request and gives a breakdown of the types of changes (backward incompatible or no, etc). Based on this it recommends what the next release of the project should be.

At the moment it only works for opensource PHP projects, I invite you to give it a spin on an opensource project you may be working on. Feedback would be hugely appreciated.

Many thanks!

Hi all,

I'm helping to prototype a beta for a service that will integrate with GitHub to analyze Pull Requests for backwards compatibility. This whole thing came from a lot of pain with internal projects when we mistakenly introduced backwards-incompatible changes into libraries only to have everything explode mysteriously when dependencies on the projects using the libraries were updated, something that should go smoothly if Semantic Versioning is used correctly by all dependencies.

I'd love your feedback, is this a problem for you? Which programming languages would benefit from this most? (I come from a PHP background but I get the impression that JS folk get a lot of heartache because of this too, is that true?).

Thanks!

This post tries to dispel any belief that docker swarm is not production-ready :P

Excellent! Thanks for the detailed description!

Documentation is scarce, I had understood that Docker 1.12 uses it's own service discovery mechanism.

From here (https://docs.docker.com/engine/swarm/swarm-mode/#view-the-jo...):

"...starts an internal distributed data store for Engines participating in the swarm to maintain a consistent view of the swarm and all services running on it"

Here are the docs for "swarm init" in docker 1.12: https://docs.docker.com/engine/reference/commandline/swarm_i...

Definitely possible that I'm misusing the term bare-metal but nope, no VMs, I meant 1000 (bare-metal) servers with only docker installed

EDIT: I had been misusing the term bare-metal, thanks for picking up on it. Examples should hold on both bare metal and VMs though.

Maybe I'm misunderstanding what you mean by "cluster node store" but in Docker 1.12 its built in, setting up a swarm is now really easy. No need for consul, etcd, etc. It's high available by default.

I use Jekyll (https://jekyllrb.com/) which generates static html pages from templates and your blog posts written in markdown. The advantage of this is that I can put my entire blog in git. Also there is no database needed, which makes hosting much easier.

I generate the static html and then put them inside a docker container to deploy. The host is a bare metal server (not free but cheap) with docker installed.

Both of these blogs use Jekyll + Docker as described above:

- http://blog.nimbleci.com/

- http://blog.emmetogrady.com/