Release process and GitHub Action to release a NuGet packages, based on tags.

[entvex]

Fixes Issue Link: GitHub Issue #117 Issue Link: GitHub Issue #159 Issue Link: GitHub Issue #28

Description

This GitHub Actions (GHA) workflow automates the release process for our software to NuGet. The NuGet package is versioned based on git tags.

The process among other things involve using GitHub releases:

1. Create or select an existing tag.
2. Enter a release title.
3. Generate release notes.
4. Push the release to GitHub.

For detailed explanation, please read release-process.md in this commit.

Testing

Testing this workflow is challenging since GitHub doesn't offer a straightforward testing environment. I initially tested it on my personal project, nugettestrepo_delete_me_soon, and confirmed its functionality. Later, I adapted the GHA configuration to match the DotPulsar folder structure. Unfortunately, due to GitHub's limitations, there are no comprehensive testing options available beyond these steps.

[entvex]

Dear @eolivelli, We are aware of this and if you want to follow the discussion please see https://github.com/apache/pulsar-dotpulsar/issues/159. Also, this PR is a draft, so it can't be merged yet. 😄

[tisonkun]

I'll review this patch in the next week.

[dave2wave]

@eolivelli is correct and the release must be VOTED on as a source release. Once that passes then pressing a button to build and release a convenience binary to a packager may be acceptable to the ASF. @tisonkun I think you know where you can have that discussion.

[tisonkun]

may be acceptable to the ASF

Yes. This is what I implement for Apache OpenDAL (incubating) - https://github.com/apache/incubator-opendal/blob/bb438d80f7bbea2285611957b3f6fa6098ce7f9e/.github/workflows/bindings_nodejs.yml#L198-L246

where you can have that discussion

I will start a DISCUSS in dev@ for broadcasting this PR, and review the release process proposed here to ensure the process is correct as INFRA member did in https://github.com/apache/incubator-opendal/pull/2729. @dave2wave I'll appreciate it if you can check the release process here.

[tisonkun]

Cross-reference - https://lists.apache.org/thread/kvvc2qlfo4b2bj28n0fz5d8szoxoo1o0

[entvex]

Seems like we don't create a branch for the Major and Minor versions. How do we maintain the patch release for the specific version?

Hi @RobertIndie. When we need to create a backporting patch, we simply create a branch for the version that requires the backport. We can easily locate a specific version using git tags. It is not necessary to create a branch until the actual need arises. We have previously backported a patch, and if you would like to see it, please refer to the image below.

If anything is unclear, please let me know.

[RobertIndie]

Hi @RobertIndie. When we need to create a backporting patch, we simply create a branch for the version that requires the backport. We can easily locate a specific version using git tags. It is not necessary to create a branch until the actual need arises. We have previously backported a patch, and if you would like to see it, please refer to the image below.

It's better to make it clearer in the release process. Like how to create a maintenance branch and how to perform the patch version release.

[blankensteiner]

Hi @RobertIndie I'm not sure what you mean by making it "clearer in the release process"? Are you advocating creating the branch or are you saying that some Git 101 "how to"-documentation is missing? Regarding the branches: It makes sense to create a branch when it is needed and not before. In 99% of the cases, we are not gonna need it. Regarding documentation: You are welcome to add any documentation you feel is missing.

[RobertIndie]

@blankensteiner I'm not referring to the Git 101 "how to" doc.

For this statement:

When we need to create a backporting patch, we simply create a branch for the version that requires the backport. We > can easily locate a specific version using git tags. It is not necessary to create a branch until the actual need arises. We > have previously backported a patch, and if you would like to see it, please refer to the image below.

Yes, it's clear to me now. However, I couldn't get this information from the release process. I think it's better to add it to the release process.

Also, I'm +1 for this way of handling the maintenance branch. In most cases, we don't need to maintain the old version branch.

[entvex]

Hi @RobertIndie. I have added Managing backporting of patches to release-process.md. If you think more is text is needed feel free to add it 😄

[tisonkun]

Thanks for your review and preparation :D

I'll double check the version tomorrow and pending to pull the trigger :D