-
Notifications
You must be signed in to change notification settings - Fork 215
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
Goal of the releases folder #96
Comments
I gotta admit, you've been turning me on to many nifty stuff. Unpkg is cool, and I was not aware of it — when did it come in to existence? I'm skeptical it has been around for more than a few years, but I've been wrong before. The main goal of the Keeping current is important indeed, but please consider, there are many users, systems, and processes downstream - hopefully automated, but nonetheless, pre-existing, that use a library like I'm quite sure that peeps using Unpkg don't give a hoot about the releases folder. However, if someone is relying on it, they will care a whole bunch if it goes away or ceases to get updates. |
@flitbit Thanks so much for the clarification!!!
That's a very good point! I never thought about it.
That part I still can't understand. A person will only receive the updates if he/she update the package. For that the versioning of the package managers exists, if you want an older version you will install the older version instead of installing the newest version and import the an older version present in a folder at the package. |
@thiamsantos There is life beyond package managers. All releases are published to npm - that's the only package manager I've supported directly. Bower and Component were special requests that I received at one time or another.
This statement ignores the fact that many good engineers automate their processes by scripting. Think back to a time before package managers (most programming ecosystems didn't use them at all just 10 years ago)... engineers would put together workflows in script (bash, py, perl, etc.) to eliminate the tedium of tracking updates in their dependency graph. I assure you, such scripting is still an integral part of systems deployed all over the world - and until there is a package manager that rules the world, these intermediate scripts will continue to be written to bridge the gaps between languages, operating systems, and the multitude of ways things are "published" on the web. We'll never know how many scripts monitor the repo's release tags, pull a new release from the predictable place (in the I am wary of breaking such automation in scripts that I've never seen but can easily imagine. I myself have many systems in operation that use hand written, automated workflows to pull/monitor published assets from strange locations on the web. I like to author systems for a particular purpose, write it [reasonably] well, and forget it. It is always aggravating when I am forced into a modification of something that has worked well for years. As you can see by the Typescript issue #97, others are aggravated by unexpected change as well. It is unpredictable what others have chosen to do with what you've published. |
@flitbit Now I'm understanding! Thank you so much for taking the time to clarify this question for me. |
What's is the main goal of the releases folder? An user install can't junst install an different version of the module? Or use an cdn like unpkg?
The text was updated successfully, but these errors were encountered: