Implement new release process

[andygrove]

Which issue does this PR close?

N/A

Rationale for this change

Development of the Python bindings has been lagging behind DataFusion because we have to wait four weeks to get the next DataFusion release before we can update the Python bindings.

I would like to change our release process and branch policy so that we can keep the main branch branch up-to-date with the latest DataFusion using GitHub dependencies and then create release branches when we are ready to create a new release.

What changes are included in this PR?

• Documentation for new release process (rendered version)
• Modification to one workflow

Are there any user-facing changes?

No

[andygrove]

@alamb @jdye64 fyi

[alamb]

Other than the reference to "github dependencies" this process makes sense to me

[raulcd]

@andygrove I know this is not strictly related to this PR but I got a minor question reading the rendered release process.

I can see we are publishing artifacts to Anaconda before the vote, shouldn't this be done after the successful vote?

Let me know if you prefer me ask this opening a new issue on ASF slack / Zulip (we have too many possible places).

[andygrove]

@raulcd Thanks for noticing that. The instructions are indeed incorrect and need some refinement to make it clear that we should publish only from the released tarball. I will update this PR.

[andygrove]

@andygrove I know this is not strictly related to this PR but I got a minor question reading the rendered release process.

I can see we are publishing artifacts to Anaconda before the vote, shouldn't this be done after the successful vote?

Let me know if you prefer me ask this opening a new issue on ASF slack / Zulip (we have too many possible places).

I filled #237 to address this