.NET release: align package name and trigger strategy before enabling publication

[Xuanwo]

Summary

The current .NET release workflow appears to be wired for publishing a NuGet package, but there are still a few product and release-policy questions that should be resolved before we rely on it.

Current concerns

1. The published package name does not appear to be aligned with the expected product name.

   Today the project is defined as DotOpenDAL (bindings/dotnet/DotOpenDAL/DotOpenDAL.csproj), and there is no explicit PackageId override. That likely means the published NuGet package name will also be DotOpenDAL.

   I would prefer the package name to be OpenDAL unless there is a strong reason to keep the language-specific prefix.

2. The release workflow currently depends on dedicated dotnet-v... tags.

   This is different from the repository-wide release flow. If .NET does not have the same kind of hard tag-format requirement as Go, I would prefer to trigger the release from the normal repository release tag instead, while still allowing the .NET package to use its own internal version number.

   In other words:

   • release trigger: repository tag
   • package version: .NET-specific version if needed

3. If the release story is not fully ready yet, we should not leave the publishing workflow half-enabled.

   In that case, it would be better to disable the .NET release action for now and re-enable it after the package naming and trigger strategy are finalized.

Proposed direction

• Decide whether the NuGet package name should be OpenDAL or DotOpenDAL.
• Clarify whether .NET really needs a dedicated dotnet-v... tag namespace.
• If not required, switch the workflow to use the standard repository release trigger.
• If the release process is still incomplete, disable the publishing workflow temporarily to avoid accidental or confusing releases.

Why this matters

Release mechanics become user-facing very quickly:

• package naming affects discoverability and long-term ecosystem consistency
• tag strategy affects operational simplicity and cross-language release maintenance
• partially enabled publish workflows create avoidable release risk

Follow-up

Once we agree on the desired release contract, we can update:

• the .csproj package metadata
• the GitHub Actions trigger conditions
• the release documentation

[Xuanwo]

cc @Fatorin and @tisonkun for comments.

[Fatorin]

I agree that we should not proceed with an official release yet, as the stability of this package has not been fully verified.

NuGet Trusted Publishing is not yet activated, so the current workflow will not publish packages to NuGet.

Based on the dotnet pack documentation, we can control the package version via additional parameters, so there is no need to introduce a special dotnet- tag format.

We can derive the package version directly from the repository tag and pass it to dotnet pack via /p:PackageVersion, which avoids hardcoding the version in the .csproj. This also allows us to handle RC or test versions more cleanly.

Since the package is still in a testing phase, I’m considering enforcing an RC suffix during packing for now (e.g., --version-suffix "rc"), with proper normalization if the tag already includes an RC suffix.

I will open an issue and submit a PR within the next couple of days to address these points.

And I recommend using OpenDAL instead of DotOpenDAL.

[Xuanwo]

Great, thank you!