I didn't see a consensus on this topic yet, and a tools release is about to get rolling by Steve.
My original driver for this discussion is that if we are going to do shrinkwrap, that we do it all the way instead of slapping it on at the end. Doing it does add more complexity. But it also removes variability, that's the part I like. If the majority of folks want to skip the shrinkwrap, I would be OK with that as long as we specifically pin all our dependencies ( "foobar": "1.2.3" ) in our package.json files (no ".x", no tilde, caret, greater-than, etc). That would handle the 1st-level dependencies, but not subdependencies since we don't have control of their package.json - it's partway to the destination at a lower cost. This also assumes that partway to the destination is good enough. I did add a step to the tools release that the pinned versions get updated at the beginning of a release: https://git-wip-us.apache.org/repos/asf?p=cordova-coho.git;a=blobdiff;f=docs/tools-release-process.md;h=02d28c97e8dd104528035939049515338347c75b;hp=b5d288b2c5a8d3cb03bb8fc050bf26c8d15d28fb;hb=8ca35fe00cf0e72eb70d05e242fe7021ec65b028;hpb=14983eb014f84e08e7a76f1ab6ffe069b81f6ffa Comments? On Sep 22, 2014, at 10:01 AM, Andrew Grieve <agri...@chromium.org> wrote: > I like having it in. For CCA, we actually did get bit in a release where we > didn't have a shrinkwrap and a descendant dependency changed and broke > things on us. > > It's also really nice that when we sign and vote on a release, that doing > an "npm install" on it down the line will recreate the exact thing we > tested & signed. > > I think the trouble came along here just from incomplete release step > instructions. I think that this (lack of clear steps / process) is the real > problem.
