-
Notifications
You must be signed in to change notification settings - Fork 166
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
Releases: Provide parsable catalog files of releases #22
Comments
To sum up from the other issue, something easily parseable in a shell, with version number, shasum, and binary URL, would be wonderfully helpful. |
Something like http://ftp.debian.org/debian/dists/testing/Release ? I think we could change the hashes with the list of packages to something like a hash with the list of releases tarballs ?? It comes to my mind something like:
This allows us to give out several extensions of the same file and it's very easily parseable by a simple sed + awk script and from that create a JSON file. |
I've created an initial format for a catalogue, currently on nightlies but will also be on dist: index.json and index.tab I'd really like feedback from version-manager authors on this, discussion happening in nodejs/node#301 (comment) for now /cc @aaronpowell |
derp, fixed |
fixes #64. when a given version is requested, https://iojs.org/dist and http://nodejs.org/dist are checked for that version, in that order. `latest` always refers to io.js, because checking for node 1.0 is a bit of a waste of user time. `stable` always refers to node.js, because there is no stable release of io.js yet, and we have no way of determining that programmatically yet anyway, pending nodejs/build#22. the two-repository fallback hackery can also disappear once nodejs/node#420 is fixed.
Referencing nvm-sh/nvm#616 |
@rvagg it seems this can be closed now? |
Continuing nodejs/node#40 here. The summary is that to help version managers do their job with io.js we need to provide parsable catalog files detailing what releases are available (and perhaps other metadata).
Suggestion for now is to provide both a simple .txt file list in the same directory as release tarballs as well as a .json file that is extensible so we can put in additional metadata like shasums. See the comments in nodejs/node#40 for some great ideas.
The build team need to come up with a proposal for how it'll work before passing it back to the TC for acceptance. Be sure to include other interested parties in the discussion.
/ @smikes @ljharb @kenperkins @alexgorbatchev @keithamus @naholyr @mostman79 @gkatsev @Fishrock123 @arb
The text was updated successfully, but these errors were encountered: