Even with pinned dependencies, we run into the problem that it's tough to ship multiple modules that depend on each other at the same time because cordova depends on cordova-lib.
How about we stop using -rc# suffixes for our release candidates? E.g. For each RC, was actually do just bump the patch version and dist-tag it as @rc instead of @latest. If it doesn't work out, we bump the patch and try again. This will mean that it will be normal for our versions to jump by more than 0.0.1 each time, but I don't think that's actually a problem. We can then vote on RCs, and the final step of making the RC published, is just to switch the dist-tag rather than any re-packaging. On Mon, Sep 29, 2014 at 7:09 PM, Jesse <purplecabb...@gmail.com> wrote: > +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. > > > > >
