emscripten-releases-tags.txt

{
  "latest": "1.38.42",
  "releases": {
    "1.38.42": "05f8c01394ddd0838d3cb484ba8ca97a3efc1ac9",
    "1.38.41": "5c6785a63993ae7a4d5362b32b0be9c85138fb96",
    "1.38.40": "7b4b328af02eafbc857b8ca1e3d9b12dddc56ef7",
    "1.38.39": "f42b12c45fd3f4c20de1321402fbc28f8fd21df1",
    "1.38.38": "80bff2784f8500c1305ca69ba1d9fc84df0e401c",
    "1.38.37": "0ca6c49e30bc09c3ccefc867df4196a4b4183441",
    "1.38.36": "d46be49c2aab975333423122239892bd46f52bba",
    "1.38.35": "98f49919f25e06fa557cbcb1321d4c10e60c87ca",
    "1.38.34": "048cf9424790cc525a7ea6da340820aae226f3b9",
    "1.38.33": "3b8cff670e9233a6623563add831647e8689a86b"
  }
}
Prepare for emscripten-releases (#237) Updated to our current initial plan here: * Add emscripten-releases-tags.txt which is a JSON file with a map of tag name to git hash in the emscripten-releases repo. Right now this file is just checked in here; in the future we may make the emsdk update it from git tags with update-tags etc. * That file contains a "latest" tag, which is fetched for when getting latest-releases-[upstream\|fastcomp]. We may want that to eventually be updated based on the latest green stuff on the bots perhaps. * Rename the current sdk-[upstream\|fastcomp]-* etc. to sdk-waterfall-[upstream\\|fastcomp]-. Then we'll have sdk-releases-[upstream\|fastcomp]- etc. This is just an internal name change - emsdk install latest-upstream still works as before, and still uses the waterfall (so we don't break our github CI). * Add support for emsdk install latest-releases-[upstream\\|fastcomp] * Add a test using the actual emscripten-releases builds 2019-05-22 17:23:04 -07:00			`{`
1.38.42 (#321) 2019-08-19 14:36:20 -07:00			`"latest": "1.38.42",`
Add emscripten-releases support for release tags (#243) * Structures emscripten-releases-tags.txt to mention the latest release, and then a list of all previous releases. * Adds a new release for 1.38.33. * If the manifest has emscripten_releases_hash, then we write out emscripten-version.txt with the proper version. We start with the hash, and check if there is a released version for it, if so we emit that, otherwise we emit the hash. * Windows zipfile fix. 2019-05-23 17:08:23 -07:00			`"releases": {`
1.38.42 (#321) 2019-08-19 14:36:20 -07:00			`"1.38.42": "05f8c01394ddd0838d3cb484ba8ca97a3efc1ac9",`
1.38.41 (#317) 2019-08-07 10:39:51 -07:00			`"1.38.41": "5c6785a63993ae7a4d5362b32b0be9c85138fb96",`
1.38.40 (#304) 2019-07-24 13:34:19 -07:00			`"1.38.40": "7b4b328af02eafbc857b8ca1e3d9b12dddc56ef7",`
1.38.39 (#302) 2019-07-16 13:17:56 -07:00			`"1.38.39": "f42b12c45fd3f4c20de1321402fbc28f8fd21df1",`
1.38.38 (#296) 2019-07-08 20:29:04 -07:00			`"1.38.38": "80bff2784f8500c1305ca69ba1d9fc84df0e401c",`
1.38.37 (#290) 2019-06-26 10:55:51 -07:00			`"1.38.37": "0ca6c49e30bc09c3ccefc867df4196a4b4183441",`
1.38.36 ; Check if all downloads exist for the latest version (#278) This verifies all builders successfully uploaded builds for a new version that we tag here. This prevents a problem like happend on 1.38.35, where the mac and windows bots "skipped" the hash that we tagged - they built the one before, and I guess were too slow, so they skipped to the next commit after it? Which is expected I guess, but surprises me a little. Anyhow, with this fix we should avoid such problems in the future. Tags 1.38.36 to verify things work and get people a working version. Also check some other basic things: check the version built reports the right one in emcc -v, and that multiple emsdk updates still work. 2019-06-15 12:00:54 -07:00			`"1.38.36": "d46be49c2aab975333423122239892bd46f52bba",`
Emscripten 1.38.35 (#276) This brings in the libtinfo changes. As a result this may fix breakage for some linux users, at the cost of some linux users possibly losing colors in the console (since sometimes that doesn't work with libtinfo not linked in). 2019-06-14 17:54:26 -07:00			`"1.38.35": "98f49919f25e06fa557cbcb1321d4c10e60c87ca",`
Tag 1.38.34 (#258) This should fix some version warnings people are currently seeing - we removed the fastcomp version warnings between repos check after the last version, in emscripten-core/emscripten#8664, #259 2019-06-02 09:11:46 -07:00			`"1.38.34": "048cf9424790cc525a7ea6da340820aae226f3b9",`
Add emscripten-releases support for release tags (#243) * Structures emscripten-releases-tags.txt to mention the latest release, and then a list of all previous releases. * Adds a new release for 1.38.33. * If the manifest has emscripten_releases_hash, then we write out emscripten-version.txt with the proper version. We start with the hash, and check if there is a released version for it, if so we emit that, otherwise we emit the hash. * Windows zipfile fix. 2019-05-23 17:08:23 -07:00			`"1.38.33": "3b8cff670e9233a6623563add831647e8689a86b"`
			`}`
Prepare for emscripten-releases (#237) Updated to our current initial plan here: * Add emscripten-releases-tags.txt which is a JSON file with a map of tag name to git hash in the emscripten-releases repo. Right now this file is just checked in here; in the future we may make the emsdk update it from git tags with update-tags etc. * That file contains a "latest" tag, which is fetched for when getting latest-releases-[upstream\|fastcomp]. We may want that to eventually be updated based on the latest green stuff on the bots perhaps. * Rename the current sdk-[upstream\|fastcomp]-* etc. to sdk-waterfall-[upstream\\|fastcomp]-. Then we'll have sdk-releases-[upstream\|fastcomp]- etc. This is just an internal name change - emsdk install latest-upstream still works as before, and still uses the waterfall (so we don't break our github CI). * Add support for emsdk install latest-releases-[upstream\\|fastcomp] * Add a test using the actual emscripten-releases builds 2019-05-22 17:23:04 -07:00			`}`