+1 to pinned dependencies, and no shrinkwrap @purplecabbage risingj.com
On Mon, Sep 29, 2014 at 1:45 PM, Marcel Kinard <cmarc...@gmail.com> wrote: > 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. > >
