Prepare repository for 2.0.0 alpha

[erikengervall]

• Add documentation for new features
• Publish image used in aws-codebuild example

[erikengervall]

Hey @n1ru4l,

I've started prepping the repo for a version bump (I'll add items to the list above as I discover them).

When reading up on the code introduced in #91, I’m curious what the Dockerfile looks like for n1ru4l/aws-codebuild-node:7712cfae8d65fd3b704f74e84f688739de5bd357. I can’t really infer what image it’s based FROM and don’t really understand how some of the commands in the IMAGE HISTORY works, e.g:

• ADD file:a86aea1f3a7d68f6ae03397b99ea77f2e9ee901c5c59e59f76f93adbb4035913 in /
• COPY file:8ed4998079558ad804ead7c9d07c43def00bded2153653739360bd8d8c7ffe0c in /usr/local/bin/

Could you explain briefly what’s going on?

[n1ru4l]

It is basically the aws-codebuild Image but I added Nodejs 10. I should put it in a repo on github 😅

[erikengervall]

It is basically the aws-codebuild Image but I added Nodejs 10. I should put it in a repo on github 😅

That'd be awesome! Transparency all the way 🙂

[erikengervall]

Considering the amount of changes that is going into the next release, is a major version bump justified? @n1ru4l

[n1ru4l]

Major release bump is definitely justified!

There are quite some more things in the backlog that will be (potential) additional major version bumps. I personally would categorize these features as crucial.

• Consider leveraging docker healthchecks #85
• collect container logs #80

We could release a 2.0.0 alpha with the current changes and then the final 2.0.0 once the issues are addressed.

That way we do not have to publish a 3.0.0 right after 2.0.0.

TBH I do not care to throw out major version bumps regularly. However, it could be tedious for people that use this library.

I am definitely against breaking changes outside a major release.

Let me know what you think about this!

[erikengervall]

It is basically the aws-codebuild Image but I added Nodejs 10. I should put it in a repo on github 😅

Did you create a repo for the image? Ideally I'd want to be able to refer to it in the documentation in the next release.

---

Major release bump is definitely justified!

There are quite some more things in the backlog that will be (potential) additional major version bumps. I personally would categorize these features as crucial.

• Consider leveraging docker healthchecks #85
• collect container logs #80

We could release a 2.0.0 alpha with the current changes and then the final 2.0.0 once the issues are addressed.

That way we do not have to publish a 3.0.0 right after 2.0.0.

TBH I do not care to throw out major version bumps regularly. However, it could be tedious for people that use this library.

I am definitely against breaking changes outside a major release.

Let me know what you think about this!

I think we're on the same page 👍 I really don't want to publish breaking changes in minors/patches. Publishing majors regularly isn't something I mind in principal, but like you say, alpha/beta-releases could be a way to reduce the number of major bumps.

[n1ru4l]

Did you create a repo for the image? Ideally I'd want to be able to refer to it in the documentation in the next release.

https://github.com/n1ru4l/docker-image-node-10-with-docker-and-compose

[erikengervall]

2.0.0-alpha.1 published 🎉