-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alias --tag
to --channel
#4926
Comments
Where is this term “commonly” used? |
Here are the relevant hits on duckduckgo when you search for "release channel". https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels These are all on the first page. It is broadly used in the industry, and fairly well understood by users. Firefox also has release channels. Almost any Web dev is already familiar with the term used for this meaning. It is more meaningful and specific than tag. |
A release channel is a common concept for particularly large projects. However, npm tags - and git tags - are both used quite commonly not for that, and also both used for that. This alias would be confusing. npm's command is |
Large projects appear on the first page of search results. Channels are used by projects of all sizes. I'm not saying tags are not used for other scenarios, but I haven't seen any in the wild (though I'd love to see common examples of other uses). It's funny you compare git and npm tags, as they are nothing alike. npm tags map to git branches, npm versions map to git tags or commits. edit: clarity |
I maintain over 300 projects that use git tags and npm tags, and don't use the concept of "release channels" whatsover. The concept basically does not appear at all outside of large projects. npm tags map to an npm package tarball, not to anything about git whatsoever. git tags map to a git sha, which might be a branch, or not. |
git branches are mutable pointers to the growing end of an append-only1 list of immutable2 commits. npm tags are mutable pointers to the growing end of an append-only3 list of immutable4 versions. These may look very different at a glance, but if you squint a bit and blur the lines you'll see these graphs commute. In well maintained packages The smallest packages have a single release channel: 1, 2, 3, 4 caveats apply Edit: I'm being told that I must be more explicit in my wording... Could you provide examples of common uses of npm tags that aren't release channels, as defined above? |
Your definition establishes that everyone is using release channels. But that’s simply not true - i have over 300 projects that do not employ that concept and for which i do not use that term, and for which npm tags are simply not used in that fashion. I even have packages where i backport to multiple minors and majors, and delete the npm tags once I’m done - there’s no such concept for me as “release channel”. |
First...
Adding to the fact that you are a npm CLI maintainer, that makes you a big outlier in terms of package release experience. It doesn't mean your experience and use cases should be discounted (especially given the value these pacakges provide), but it means that they are far removed from the ones of typical users. Release channels as streams of releases for specific audiences is not my invention, it is an industry-wide accepted definition. Semver and semver queries ( When you bump npm however, will not let you publish packages without associating an explicit A I've also looked a bit into the origins of It is also seldom used. Most users will never publish a package. Most package authors only publish to The Package authors who reach that mile stone generally first clobber As far as I'm concerned, I use it rarely, and it took me an inordinate amount of time to permanently memorize the flag name, because "tag" in my mind is strongly tied to immutable refs, since that what they are in practice in git (and git tags are more in your face as a dev/author, e.g. in the GH UI, or when you publish a package version). I knew the option existed, but I could never recall its name, the static/stream contrast creates dissonance that's hard to overcome. After a while, I got it to come intuitively, but then doubt crept in and I had to double-check. This learning experience is sub-optimal and could be improved. I'd be surprised if I was the only one.
|
I agree a That said, I don't agree that the concept of release channels is widely understood. node has them, and users are constantly confused about what they are and how they work. (Git tags are 100% mutable; that they're used immutably in practice is irrelevant) |
Beside mathematical constants, everything is 100% mutable. Immutability is approximated by social, physical or computational constrains that can be bypassed with sufficient power. How git tags are used in practice is very relevant to how people perceive them, yes. In npm-related projects 99%+ of the time, tags are used to point to commits that correspond to npm releases, which are ~immutable (for the common dev). That's an implicit social contract that is very well respected. |
So, beside your use case which uses |
The most common usage is a “next” tag, which is a version that is in the same “conceptual” release channel, but isn’t ready for broad usage, but isn’t a prerelease. These authors aren’t thinking about release channels at all - that mental model is an extreme rarity among package authors. |
Now that's interesting. I would have thought of They are two distinct streams of releases, for distinct purposes (which coincide when How do you put |
By just “doing that”. There’s no such thing as a “release channel” concept in npm, as I’ve been saying. You can choose to use npm tags to encapsulate release channels, but that’s something you’re imposing - it’s not part of the inherent model. Most users, i argue, don’t understand that concept at all, let alone apply it to npm tags. In other words, even if adding any alias would be worth it (it wouldn’t), this one in particular would be far more confusing for most. |
Re. "by just doing that", that's begging the question. We'd need to survey users to get a definitive answer, but I think you underestimate folks out there. You have a broader following that I have on Twitter, would you mind posting a survey:
|
Fourth option
Twitter has 25 character limits for poll options. I went for I encourage you to post as well (or RT https://twitter.com/pygy/status/1528781062217900036), you'll get a broader sample, and our respective audiences probably share our biases. |
npm has called them that's not to say that we won't do something like this, release channels might be a thing we want to support in the future, but as of today we're sticking with if you'd like to start the conversations to support release channels, please open an RRFC issue at https://github.com/npm/rfcs and see the README in that repo about our weekly public rfc meetings where you are very welcome to join and discuss with us! |
git tags and npm tags are often concomitant concerns, and having the same term for both causes unnecessary confusion.
In common parlance, npm tags are refered to as release channels, it would be nice if that was reflected into the cli options, with a
--channel
that would alias to--tag
.The text was updated successfully, but these errors were encountered: