Before considering whether to split the code into multiple modules, one must first ask if it makes sense to intermix three separate version numbers and use each project independently from the others. I would argue that it does not.
Typically, with client libraries like this, they are either fully agnostic (in which case the latest stable release is always best), or they are pinned by major or minor semver component to the package they are a client for, implementing whichever API interface is current for the matching version. As far as I know, Pulsar does not officially support pluggable *versions* of the administrative API, broker APIs, or authentication backend. Many components are pluggable insofar as an implementation class can be provided, but this is not part of the release cycle, and upgrading targets such as the authentication providers outside of the Pulsar version is not done---they are connected to the release version. There is no setting for authorizationProviderVersion or adminAPIVersion. Given that pulsar-client-go represents the primary client interface to pulsar, and given that both pulsar-client-go and pulsar-admin-go interact with the same Pulsar version in any given deployment, I would vote that they all live underneath of `pulsar-client-go` and are versioned together. On Mon, Jul 31, 2023 at 11:59 AM Zixuan Liu <node...@gmail.com> wrote: > This is a good idea for the Pulsar community. > > > The first one is hosting code in three repos: pulsar-admin-go, > pulsar-client-go, pulsar-auth-go. Then factor out the shared auth logics > into pulsar-auth-go and let pulsar-admin-go and pulsar-client-go depend on > it. > > I prefer this idea. The `go get` depends on the git tag/branch/commit, > when three modules are in one repo, this version number can cause > confusion. > > Thanks, > Zixuan > > 太上玄元道君 <dao...@apache.org> 于2023年7月31日周一 17:19写道： > > > > +1 > > > > Thanks, > > Tao Jiuming > > > > Yunze Xu <x...@apache.org>于2023年7月31日 周一16:26写道： > > > > > LGTM. > > > > > > Thanks, > > > Yunze > > > > > > On Wed, Jul 26, 2023 at 5:11 PM tison <wander4...@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > ## Motivation > > > > > > > > Pulsar brokers serve two kinds of client-side requests: data panel > > > requests > > > > (often known as client-api) and control panel requests (often known > as > > > > admin-api). > > > > > > > > Pulsar has multiple client libraries support among Java, C++, Python, > > > > Golang, C#, Node.js, etc. While most of them implement the > client-api, > > > > currently, only the Java library implements the admin-api. > > > > > > > > Nowadays, many Pulsar deployments are in cloud environments, where > Golang > > > > dominates the domain. Thus, there is an increasing requirement to > make > > > > control panel requests with integrations of those Golang libraries. > > > > > > > > StreamNative invented pulsar-admin-go[1] during its development of > Pulsar > > > > Cloud services. The library is open-sourced months ago[2]. > > > > > > > > Now, we’d propose donating this library to the Apache Pulsar project > > > cause > > > > Apache provides a solid way to release software, and we may find some > > > > opportunities to deduplicate code between pulsar-admin-go and > > > > pulsar-client-go. > > > > > > > > [1] https://github.com/streamnative/pulsar-admin-go > > > > [2] https://github.com/apache/pulsar/discussions/19932 > > > > > > > > ## Features > > > > > > > > pulsar-admin-go follows all the features that Java’s > pulsar-client-admin > > > > provides. Currently, it supports management over: > > > > > > > > - BrokerStats > > > > - Brokers > > > > - Clusters > > > > - Functions > > > > - FunctionsWorker > > > > - Namespaces > > > > - NsIsolationPolicy > > > > - Packages > > > > - ResourceQuotas > > > > - Schema > > > > - Sinks > > > > - Sources > > > > - Subscriptions > > > > - Tenants > > > > - Topics > > > > > > > > ## Development > > > > > > > > The open issue for pulsar-admin-go’s development is how we organize > code > > > > into repos for pulsar-admin-go and pulsar-client-go. > > > > > > > > Java’s pulsar-client-admin depends on pulsar-client. Although > > > > pulsar-admin-go doesn’t depend on pulsar-client-go, they share the > same > > > > code implementation of auth logics. > > > > > > > > Generally, maintaining duplicate code is not a good idea. So we have > two > > > > ways to avoid this situation. > > > > > > > > The first one is hosting code in three repos: pulsar-admin-go, > > > > pulsar-client-go, pulsar-auth-go. Then factor out the shared auth > logics > > > > into pulsar-auth-go and let pulsar-admin-go and pulsar-client-go > depend > > > on > > > > it. > > > > > > > > In this way, although it provides a clear boundary between modules, > it > > > may > > > > increase the burden of managing issues and releasing them. > > > > > > > > Thus, I’d prefer the second approach: hosting pulsar-client-go and > > > > pulsar-admin-go code both under the current apache/pulsar-client-go > repo, > > > > and deduplicate auth logics by letting pulsar-admin-go use the > current > > > auth > > > > logic provided in pulsar-client-go. > > > > > > > > In this way, we simplify the process of managing issues and doing > > > releases, > > > > while we should take more care of how to release these three > logically > > > > separated modules in one repo. > > > > > > > > If nowadays Golang can compile code in packages, we should be fine to > > > merge > > > > pulsar-admin-go code just into apache/pulsar-client-go in packages. > > > > Otherwise, we should refactor the code into three go modules. > > > > > > > > For version strategy, as Java’s pulsar-client-admin and > pulsar-client do > > > > simultaneous releases, pulsar-client-go and pulsar-admin-go can do > > > > simultaneous releases also. I expect that pulsar-admin-go doesn’t > evolve > > > > quite rapidly to require its own release cycle, but almost bugfixes > along > > > > with the evolution of pulsar-client-go. > > > > > > > > ## Schedule > > > > > > > > [ ] Consensus on the overall direction > > > > [ ] Consensus on the repo organizing strategy > > > > [ ] IP clearance > > > > [ ] Repo transfer and setup > > > > > > > > Looking forward to your feedback! > > > > > > > > Best, > > > > tison. > > > >
