You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is the history and older versions that are currently published for the cloudevents module. Those versions are not "cloudevents-sdk" versions.
I can see a user getting burned by this, if they switch, and then need a previous version, for whatever reason, and it not working because they forgot about the name change. What about new users who never knew the history of changing names?
Also, what real value does this name change bring, other than saving a couple key strokes? You usually only ever install things once anyway
There are only 13 dependents, and few downloads/m. What changed now?
That only counts other modules that depend on this module, not applications that are not published on npm. Also i don't think 3k+ downloads a week is "a few"
There are 0 dependents on the other package and it's easy to mirror npm versions. I've done this before. The user impact would be 13 repos would get npm warnings when installing asking them to change the dependency, which would be easy and non-breaking.
We're really at the start of this repo and I'd like to make the decision now. Please answer this question:
History aside, what would you ideally install?:
cloudevents cloudevents-sdk
I couldn't have done this before because we didn't agree to publish TypeScript types in this repo.
The user impact would be 13 repos would get npm warnings when installing asking them to change the dependency, which would be easy and non-breaking
As you soon as you ask someone to change the name of something it is a breaking change.
and i still don't know why you think it is only 13 repos. that's only the modules that depend on this module. based on that weekly download count, it looks like many more users would be affected.
As for the warning, it is nice to say that users read them, but the fact is, someone will do an npm install and not pay attention to any message.
Like TypeScript support, I'm asking for us to be open. I understand the long-term impact and wish for this change. This name doesn't align with other repos. It would be a better name and would align with other SDK names like Python, Ruby, C#, etc.
You have not provided any compelling reason to change the name of this module beyond an aesthetic desire to reduce typing by four characters. I don't think that justifies this change. This module name perfectly aligns with the Rust module. Maybe we should change the names of the Python and C# modules to better align with JavaScript and Rust.
You have not provided any compelling reason to change the name of this module beyond an aesthetic desire to reduce typing by four characters.
But this module is not an SDK. This is not a "software development kit". The set of 7 languages is the SDK, the kit. This library is a small library for handling CloudEvents, part of the SDK. The CloudEvents SDK is meant to refer to a collection of multiple libraries in different languages, not an individual language library.
Moreover, this name with "-sdk" is not idiomatic for JavaScript and Node. It would be more acceptable for other languages like Java.
The only real example of a npm package using "-sdk" was AWS' SDK, which is not comparable to this library. That package is really a set of tools for multiple APIs and is aptly named.
This whole repo used Java-like constructs like builder patters. Using -sdk is one of the historical parts that I would like to fix now. It's doable like moving to TypeScript. I'd like strong counterarguments for saying no, it's not idiomatic or better due to the above arguments.
Activity
lholmquist commentedon Jun 8, 2020
I would argue that it would create more confusion if the name changed now.
I would suggest that you, @grant , deprecate that module and point your readme to this repo.
grant commentedon Jun 8, 2020
I don't think it would create confusion. There are only 13 dependents, and few downloads/m. What changed now?
History aside, what would you ideally install?:
cloudeventscloudevents-sdkI'd rather show
npm i cloudeventson stage.lholmquist commentedon Jun 8, 2020
The problem is the history and older versions that are currently published for the
cloudeventsmodule. Those versions are not "cloudevents-sdk" versions.I can see a user getting burned by this, if they switch, and then need a previous version, for whatever reason, and it not working because they forgot about the name change. What about new users who never knew the history of changing names?
Also, what real value does this name change bring, other than saving a couple key strokes? You usually only ever install things once anyway
lholmquist commentedon Jun 8, 2020
That only counts other modules that depend on this module, not applications that are not published on npm. Also i don't think 3k+ downloads a week is "a few"
lance commentedon Jun 8, 2020
I'm with @lholmquist on this. I don't think it would be wise to change the module name after two major version releases.
grant commentedon Jun 8, 2020
There are 0 dependents on the other package and it's easy to mirror npm versions. I've done this before. The user impact would be 13 repos would get npm warnings when installing asking them to change the dependency, which would be easy and non-breaking.
We're really at the start of this repo and I'd like to make the decision now. Please answer this question:
I couldn't have done this before because we didn't agree to publish TypeScript types in this repo.
lholmquist commentedon Jun 8, 2020
As you soon as you ask someone to change the name of something it is a breaking change.
and i still don't know why you think it is only 13 repos. that's only the modules that depend on this module. based on that weekly download count, it looks like many more users would be affected.
As for the warning, it is nice to say that users read them, but the fact is, someone will do an npm install and not pay attention to any message.
My vote is to keep the name the way it is.
grant commentedon Jun 8, 2020
Hi @lance, @lholmquist, Can you please answer this question?
Like TypeScript support, I'm asking for us to be open. I understand the long-term impact and wish for this change. This name doesn't align with other repos. It would be a better name and would align with other SDK names like Python, Ruby, C#, etc.
lance commentedon Jun 9, 2020
You have not provided any compelling reason to change the name of this module beyond an aesthetic desire to reduce typing by four characters. I don't think that justifies this change. This module name perfectly aligns with the Rust module. Maybe we should change the names of the Python and C# modules to better align with JavaScript and Rust.
grant commentedon Jun 9, 2020
But this module is not an SDK. This is not a "software development kit". The set of 7 languages is the SDK, the kit. This library is a small library for handling CloudEvents, part of the SDK. The CloudEvents SDK is meant to refer to a collection of multiple libraries in different languages, not an individual language library.
Moreover, this name with "-sdk" is not idiomatic for JavaScript and Node. It would be more acceptable for other languages like Java.
The only real example of a npm package using "-sdk" was AWS' SDK, which is not comparable to this library. That package is really a set of tools for multiple APIs and is aptly named.
Here are more data points:
Look at:
https://www.npmjs.com/
Search SDK in npm:
https://www.npmjs.com/search?q=-sdk
Read about SDK on Wikipedia referencing multiple tools:
https://en.wikipedia.org/wiki/Software_development_kit
This whole repo used Java-like constructs like builder patters. Using
-sdkis one of the historical parts that I would like to fix now. It's doable like moving to TypeScript. I'd like strong counterarguments for saying no, it's not idiomatic or better due to the above arguments.feat: use npm name cloudevents
feat: use npm name cloudevents (#260)