Another layout for badges

[maxmeyer]

Summary

Another layout for the build badges in the readme

Details

As pointed out in #469 I think having a talble for the build status of "master" and "still" is easier to read. But I see the point in having some kind of a "sign post" for outsiders in what kind of state the project is.

This is why I moved up the "build" bages of the "master" branch.

I also added more details to clarify the use of the branches.

Screenshots (if appropriate):

https://github.com/cucumber/aruba/tree/feature/other-layout-for-badges

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (cleanup of codebase withouth changing any existing functionality)
• Update documentation

Checklist:

• I've added tests for my code
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[junaruga]

Maybe you are a maintainer and you are going to fix current build failure/error by yourself.
I do not disagree with this.

[maxmeyer]

Maybe you are a maintainer and you are going to fix current build failure/error by yourself.

What do you mean with this?

[junaruga]

<br> HTML tag? I do not know that it makes sense for Markdown format.

[maxmeyer]

Good catch. I was not sure what the parser will do with a newline. So I took the "happy path" and just added <br> to make sure the build flags are on "their" own.

[junaruga]

I think as you are a maintainer, it is good to update README.md and the build status as you like. Because you are a person that often see the build status.
Your opinion should be prioritized.
So, I will accept your design.

[maxmeyer]

Ah ok. I was unsure if I said something impolite which I oversaw. Thanks for the feedback.

But anyway I see your point and I was not that comfortable with having the build status at the very end of the readme. Given this version in this PR it seems to be a good compromise for aruba developers and aruba users not being "disturbed" by information not interesting for that party.

It's really a good thing discussing those things and get an opinon from a different perspective. Thanks for helping making aruba better.