Create the automated release process using googleapis/release-please

[nijanthanvijayakumar]

Proposed changes

• release-please-config.json: Add configuration file with release type set to python, and the changelog path to CHANGELOG.md.
• .release-please-manifest.json: Add manifest file with quinn version set to 0.10.3.
• .github/workflows/release-please.yml: Add workflow file for release-please action
• CONTRIBUTING.md: Add a section to elaborate the "Release and Pre-Release Processes".

Types of changes

What types of changes does your code introduce to quinn?
Put an x in the boxes that apply

• Bugfix (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)
• Documentation Update (if none of the other choices apply)

Further comments

• Please refer to the *CONTRIBUTING.md* file to understand how this works. It took a bit of time to test the scenarios and understand how the release & pre-release works.
• @dinjazelena - thanks a tonne for the code.
• Closes the issue feat: Add CI for release and pre-release  #252.

[SemyonSinchenko]

@nijanthanvijayakumar @dinjazelena Thanks for the explanation! Do I understand right, that this workflow make a realease to PyPI? If so, which secrets should be provided?

[nijanthanvijayakumar]

@SemyonSinchenko - this workflow creates a GitHub release as in the screenshot below and I don't think it creates a PyPi release (I might take your help in double-confirming this @dinjazelena?). The only reference to Python I used in this workflow is here.

While creating it, I didn't see any references to PyPi and it worked on the test repo I shared earlier without involving the creation of any secrets.

[SemyonSinchenko]

Can we somehow add a step to the release pipeline that publish in PyPI release or pre-release versions?

[nijanthanvijayakumar]

Can we somehow add a step to the release pipeline that publish in PyPI release or pre-release versions?

Sure can look into it, but did you want that to be done in this PR?

[SemyonSinchenko]

Question is only do you want to create automatic release for pre-releases or for production releases

I would have better automated prod-release

[nijanthanvijayakumar]

Question is only do you want to create automatic release for pre-releases or for production releases

I would have better automated prod-release

@SemyonSinchenko - sure. I came across this article, and according to this, one doesn't need secrets to publish to the PyPI repository due to the "trusted publishing" feature. However, as indicated in the image below from the Set up PyPI publishing using GitHub section of that article, Quinn's project author or maintainer must add GitHub Actions as a trusted publisher for that project. Are you or @MrPowers able to do that while I whip up the code for publishing the package to PyPI?

Steps for adding a trusted publisher is documented in this PyPI docs here - https://docs.pypi.org/trusted-publishers/adding-a-publisher/

[nijanthanvijayakumar]

Question is only do you want to create automatic release for pre-releases or for production releases

I would have better automated prod-release

@SemyonSinchenko - sure. I came across this article, and according to this, one doesn't need secrets to publish to the PyPI repository due to the "trusted publishing" feature. However, as indicated in the image below from the Set up PyPI publishing using GitHub section of that article, Quinn's project author or maintainer must add GitHub Actions as a trusted publisher for that project. Are you or @MrPowers able to do that while I whip up the code for publishing the package to PyPI?

Steps for adding a trusted publisher is documented in this PyPI docs here - https://docs.pypi.org/trusted-publishers/adding-a-publisher/

Hello @SemyonSinchenko ! Any suggestions on the next steps?

[SemyonSinchenko]

Sorry, I missed the comment. I will ask @MrPowers

[nijanthanvijayakumar]

Sorry, I missed the comment. I will ask @MrPowers

Thanks @SemyonSinchenko

[SemyonSinchenko]

@nijanthanvijayakumar Do I understand you right that all the work is done and the only thing left is adding a trusted publihser to PyPI?

[nijanthanvijayakumar]

Yep, @SemyonSinchenko - here's the commit that contains the changes that help publishing the code to the PyPI.

[SemyonSinchenko]

@nijanthanvijayakumar LGTM overall, thanks for the effort and especially for the patience!
@dinjazelena Hi! Can I ask you to take a final look on it too?

[zeotuan]

But maybe u should guys use much more simpler way, i know i recommended this release please. What do u think about this approach. release-snapshot -> On every push to main snapshot version is created for testing release -> On every pushed tag production version is created

And all of that can be done via: https://github.com/softprops/action-gh-release

It requires few clicks more, like taking care of version number and tag. But it feels like simplicity overweights that especially with how release-please can be very hard to setup and understand.

@SemyonSinchenko @MrPowers I actually Prefer this method mentioned above which I sometimes call semi-automatic release over fully automatic prod release.
This way you can control when an actual release is supposed to be published and avoid accidental release of non-stable feature.

It's simpler, safer and easier to manage. Whoever want to use the nonstable version of the product can always pull the snapshot