DSP-618 Update release process

[kilchenmann]

resolves DSP-618

[kilchenmann]

@tobiasschweizer and @mdelez This is nothing you can test. It runs on each merged PR into master branch. I tested it on a private repo and we already implemented it in dsp-ui and dsp-app
The workflow follows the new description in README and the Contribution documentation

[tobiasschweizer]

@kilchenmann So if I understand correctly, this PR adds a release drafter that creates a release draft after each merged PR. This draft then can be turned into a prerelease.

So gren is stilled used to create the log?

[tobiasschweizer]

Why is that a breaking change?

[kilchenmann]

The corresponding PR has the label "Breaking"

[kilchenmann]

I think you're right. The endpoint for permission has changed. But this is not a breaking change for js-lib users. I can update and do a new commit

[tobiasschweizer]

EDIT Does this mean that after each merged PR, the version in package.json is changed?

Does the version number get adapted automatically now? If so, how would it be version controlled?

[kilchenmann]

With each release it takes the version number from git tag and updates the version in package.json automatically before publishing to npm.

[tobiasschweizer]

but then the change in package.json would not be updated on GitHub, would it?

[tobiasschweizer]

ah, I think now I get it: "0.0.0-PLACEHOLDER"

[tobiasschweizer]

but then just looking at the files checked out from git, how would we know the current version?

[tobiasschweizer]

hm, also true.

I am a bit concerned that we will mess up releases by mistyping the release tag

[kilchenmann]

The main problem with updating the version in the git repository: it needs always an extra commit. It needs a PR and a review because we can't push into master branch directly.

I followed angular/components and how they did it. e.g.
https://github.com/angular/components/blob/master/src/material/package.json

[tobiasschweizer]

or is there a check that compares to the previous version?

[mdelez]

I think we've based a lot of our stuff off how the Angular team works so this seems like an okay method to me. There is the possibility of typo's, but that's true in a lot of places. It's pretty convenient not having to open a PR just to change a number so I think we should try out this method and we just need to be careful when typing the release tag. We also know, thanks to me being a noob a couple weeks back, that we can stop the process from releasing a version that was mistyped/has an error.

[kilchenmann]

Thank you @mdelez
And btw we use this workflow already in dsp-app and knora-api since the day we use docker. It builds the docker image with the version defined in git-tag.

[kilchenmann]

@kilchenmann So if I understand correctly, this PR adds a release drafter that creates a release draft after each merged PR. This draft then can be turned into a prerelease.

Yes exactly. The draft can be turned into a prerelease or a real release.

So gren is stilled used to create the log?

No, we use release-drafter. Gren is still here, because we can probably use it to update CHANGELOG.md. But this will be part of another PR.
I was using gren to update the changelog manually.