On Tue, Sep 30, 2014 at 8:40 AM, Andrew Grieve <agri...@chromium.org> wrote:
> 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. > > I think it has been a while since we have used the -rc suffixes in our tools and platform releases. Don't plan on re-intrudocuing this. I think what you just described is how we have been doing the tools releases. I'll make sure the tools release doc is up to date with this information. In terms of platforms, I think we shouldn't publish them to npm under RC. It caused quite a bit of trouble last release. If you discover a problem with a platform release as it is being voted on, you then have to bump the version (eg 3.6.2 to 3.6.3), then you have to go into cordova-lib and bump the version in platforms.js as well. Once cordova-lib is bumped, you have to go into cli + plugman and bump the version cordova-lib depenendcy and bump the cli + plugman version itself. Instead, we can test platform rc's with --usegit and eventually a private npm registry for testing. > > > 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. > > > > > > > > >
