GitHub user Xuanwo created a discussion: .NET release: align package name and trigger strategy before enabling publication
## 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 GitHub link: https://github.com/apache/opendal/discussions/7345 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
