Add RELEASING.md with necessary instructions

[jajik]

close #244

[jajik]

@rhusar Looking at expected checks, we need to change the settings after #248

[rhusar]

Thats funny, doesn't seem to be very well thought out. The only option is to remove all required checks which in turn disables other functionality..

[jajik]

What? :D

edit: Oh no https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks#handling-skipped-but-required-checks

[jajik]

So it seems the workaround is this

laurencee/GithubActionTesting@876ef30

Seriously 😃

[rhusar]

Thats funny, doesn't seem to be very well thought out. The only option is to remove all required checks which in turn disables other functionality..

Just for record, it disables this one:

Require branches to be up to date before merging
This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below).

[jajik]

Just for record, it disables this one:

Require branches to be up to date before merging
This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below).

So you cannot enforce linear history without that?

[rhusar]

Just for record, it disables this one:

Require branches to be up to date before merging
This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below).

So you cannot enforce linear history without that?

I think you mean by 'linear history' changes being tested linearly / on top of each other and IIRC yes, this would remove the notification about branches not being up 2 date, which given we don't have a large turnover in this repo we want to keep.

I am thinking now let's go with your workaround.

[rhusar]

Just for record, it disables this one:

Require branches to be up to date before merging
This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below).

So you cannot enforce linear history without that?

I think you mean by 'linear history' changes being tested linearly / on top of each other and IIRC yes, this would remove the notification about branches not being up 2 date, which given we don't have a large turnover in this repo we want to keep.

I am thinking now let's go with your workaround.

OK merged - please rebase and see if this works.

[rhusar]

Just for record, it disables this one:

Require branches to be up to date before merging
This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below).

So you cannot enforce linear history without that?

I think you mean by 'linear history' changes being tested linearly / on top of each other and IIRC yes, this would remove the notification about branches not being up 2 date, which given we don't have a large turnover in this repo we want to keep.
I am thinking now let's go with your workaround.

OK merged - please rebase and see if this works.

OK thanks, the workaround looks good - and it's clear that the checks were indeed skipped.

[rhusar]

Looks good!