Community Salesforce Pub/Sub transport — guidance on package id & namespace before first publish

[meyc-v1]

Community Salesforce Pub/Sub transport — guidance on package id & namespace before first publish

Hi — I've built a Wolverine transport for the Salesforce Pub/Sub gRPC API and I'm close to
publishing a first prerelease package. Before I claim a NuGet id and a namespace permanently, I'd
like the maintainers' guidance on naming, since this is a community package and I don't want to
step on conventions (or namespaces) you'd rather reserve.

What it is

A listen-only transport: Salesforce platform events (topics, custom channels, and managed
event subscriptions) arrive as ordinary Wolverine messages with Wolverine owning dispatch, retries,
and error handling. Publishing a platform event is a plain REST POST, so there's deliberately no
sender side. (No relation to WolverineFx.Grpc — that's node-to-node; this is an external-broker
transport in the Kafka mold that happens to speak gRPC to Salesforce.)

The guiding principle throughout was "do it the Wolverine way" — I kept the Wolverine source
open and used the Kafka transport as the primary reference (ASB secondary):

• Replay tracking is a per-envelope watermark modeled on the Kafka offset committer: Track on
  receive, CompleteAsync advances the safe position, never past an in-flight envelope.
• DeferAsync re-injects for an in-memory retry, mirroring the Kafka listener.
• Listener config derives from ListenerConfiguration<,>; endpoints support Inline /
  BufferedInMemory / Durable, with the durable inbox providing at-least-once + parallelism + DLQ.
• The Avro serializer is an IAsyncMessageSerializer that persists a schema-id pointer and
  fetch-on-misses during durable recovery — same shape as the Confluent schema-registry serializer.
• Delivery guarantees per mode are live-verified against a sandbox org (kill-window and
  restart-recovery tests; the evidence logs and an ADR-style decision log ship in the repo).

Targets net10.0 against WolverineFx 6.12.
Repo: https://github.com/meyc-v1/wolverinefxcontrib-salesforcepubsub

What I'd like guidance on

1. Package id. I'm currently using WolverineFxContrib.SalesforcePubSub. Is a
   WolverineFxContrib.* prefix acceptable to you for community packages — or is there a naming
   convention you'd prefer (e.g. something that more clearly distinguishes community packages from
   the official WolverineFx.* line)?

2. Root namespace. The code currently lives in Wolverine.SalesforcePubSub (with internals
   under Wolverine.SalesforcePubSub.Internals), which matches how the official transports feel to
   consumers (opts.UseSalesforcePubSub(), opts.ListenToSalesforceTopic(...)) — but it does mean
   a community package is occupying the Wolverine.* namespace. Happy to move it out if you'd
   rather reserve that; better to change now than after anyone has using statements.

3. Versioning. My inclination is to follow your scheme to the extent an out-of-repo package
   can: track your major version (my 6.x supports Wolverine 6.x, with compatibility also
   enforced by the dependency range [6.12.0, 7.0.0)), while minor/patch stay independent — since
   your packages release in lockstep from the mono-repo, full version-tracking would either lag
   or need empty releases to keep up. If you'd rather community packages version independently
   from 1.0.0 (e.g. to avoid any implication of release-train alignment), happy to do that instead.

4. Extension method surface. The entry points are extension methods on WolverineOptions
   (UseSalesforcePubSub(...) returning a transport expression, per KafkaTransportExpression).
   If there's anything you'd want a community transport to do differently to avoid confusion with
   official surface area, I'd rather hear it pre-1.0.

Not asking for adoption or endorsement — just want to name it in a way the Wolverine community
would consider well-behaved before the id becomes permanent. Thanks for Wolverine, and for any
guidance.

[jeremydmiller]

I think the "WolverineFxContrib" prefix is the best I've got. You actually spurred us to finally go try to reserve the Nuget prefixes for "WolverineFx"

The root namespace also seems good to me.

Versioning -- ugh. I don't think you will want to have to keep up with the Wolverine release cadence. I'd just go for "1.0" when you're ready and use SemVer for your changes.

The extension methods are consistent with Wolverine idioms, I'm good with that, or really, I don't have anything to add. I'm not concerned about disambiguating contrib transports from "official" transports. I'd rather you err on the side of consistency with idioms myself.