[NEWS] Rebranding, and what to about @chili-publish/publisher-connector ?

[seancrowe]

What is going on?

Hello everyone, we are rebranding Publisher Connector to Publisher Interface. This will be the only and last time there will be a rebranding for this library.

The reason behind this rebranding is that "connectors" will have a new and distinct meaning with our new platform. The meaning is so distinct that we see major confusion among clients (new and legacy) if a publisher connector could mean this library or part of our connector system.

It is an unfortunately situation, but it must be dealt with.

Another reason for the rebranding is that in about 60 days, this will be the most popular library from CHILI publish. Over one hundred clients will be transitioning to using it. Therefore, it is even more important that the library standout from other similar named features.

This rebranding goes from this repo all the way to the NPM package. See PR #12

Will this break my integration?

@chili-publish/publisher-connector is still up on NPM. So no. Will it be updated moving forward? That is what this question is about.

However, if your moving to @chili-publish/publisher-interface then the only issue will be that the unpkg file will change both in location and name. Everything else will work the same.

What to do with publisher-connector?

How should we handle publisher-connector on NPM as the rebranding will break future updates?

[seancrowe]

My suggestion is we create a separate branch called connector, where the only difference between main and connector is the package.json file so that we can publish all pushes to that branch to NPM under the @chili-publish/publisher-connector name

This is the cleanest way to keep updating publisher-connector for those that are already using it in production.

You might wonder if this is necessary? Why not just stop updating publisher-connector? Well the reason is that we can avoid breaking current integrations, and after this quarter we do not foresee many updates to this library.

However, if we think we should kill it off, lets do so now instead of later.

[pietervp]

NPM allows deprecating a package, it will show some warnings in the console when installing, and depending on settings could prevent using it in new projects. https://docs.npmjs.com/cli/v8/commands/npm-deprecate
I suggest we deprecate and point to the new package. I don't see a need in updating the deprecated package, because upgrading will be very easy. After a certain grace period we can actually remove the package once we are sure no-one is using it anymore.

[seancrowe]

@pietervp yes it does, but removing the package may be difficult as we must meet certain criteria:
https://docs.npmjs.com/policies/unpublish

As a reply to your comment in PR #12, there is two sides of the coin. People are running this in production, although it is few, we can easily support the current package with very little extra effort.

However, being that very few are running this library, you can easily argue the opposite. It is a good time to make a clean break so as not to confuse others.

I will go with the consensus as currently I am focused on communication and compatibility, and believe the choice here in the long run is of little consequence beyond the annoyance of this name change for those who are in production.