Skip to content
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

Closed
thiamsantos opened this issue Apr 25, 2017 · 4 comments
Closed

Goal of the releases folder #96

thiamsantos opened this issue Apr 25, 2017 · 4 comments
Labels

Comments

@thiamsantos
Copy link
Contributor

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?

@flitbit
Copy link
Collaborator

flitbit commented Apr 26, 2017

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 releases folder was to provide a pre-built packages, that's all. I could have built some tooling and published it somewhere other than npm, but honestly, this is a small library, and an extraordinarily small part of my attention.

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 deep-diff once it has been in the wilde for a while. Change for the sake of change is seldom worth it. Good libraries tend to be used for their single utility; it is my opinion that we should fix what is broken, not what is old. Therefore, I have kept up the releases folder so that those that may have relied upon it, particularly in an automated fashion, aren't clobbered.

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 flitbit closed this as completed Apr 26, 2017
@thiamsantos
Copy link
Contributor Author

@flitbit Thanks so much for the clarification!!!

Change for the sake of change is seldom worth it. Good libraries tend to be used for their single utility; it is my opinion that we should fix what is broken, not what is old.

That's a very good point! I never thought about it.

However, if someone is relying on it, they will care a whole bunch if it goes away or ceases to get updates.

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.

@flitbit
Copy link
Collaborator

flitbit commented Apr 26, 2017

@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.

A person will only receive the updates if he/she update the package.

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 releases folder), and sends it downstream in a larger, scripted workflow.

I am wary of breaking such automation in scripts that I've never seen but can easily imagine. deep-diff is a top 1% npm package. I don't even know what that means in terms of possible users, but if I get aggressive about change I'm likely to find out when a mob shows up with pitchforks.

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.

@thiamsantos
Copy link
Contributor Author

@flitbit Now I'm understanding! Thank you so much for taking the time to clarify this question for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant