Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of purplecabbage@gmail.com
 designates 209.85.218.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55ED2FC4-F04D-4E13-B345-26D1EB89F32D@gmail.com>
References: <62368B3C-70D3-4ED3-B470-8BFFD1DF2EDB@gmail.com>
	<CA+GVa3bKbJ4bbmVi+mi3fk1ej1q3uqfNkRdGwp41ZSci+vA8Ag@mail.gmail.com>
	<7ef63ff7ae6f4986a7d96fd47b690437@DM2PR03MB366.namprd03.prod.outlook.com>
	<87566401-D50F-44A8-B42A-442A9325EAD0@gmail.com>
	<CADVgkyOUD5Y6S+vA7QF8hNu=J25o0w+S3Wh_2QzAiq4CiRDVQA@mail.gmail.com>
	<CAHYtTqnizpMnTT04NxR1Y20EEvMKA-5wX=BUXL7mSmbsjW0BkA@mail.gmail.com>
	<CADVgkyMKiaYO+MPJc9L-JDjW4=eZ-Y1Hu7A8pWC9d6JoGamgPA@mail.gmail.com>
	<CAHYtTqmNqjLwbue_edsMKWCSE_Yabnrc2-yaEdrsoK=-Pmsnyg@mail.gmail.com>
	<CADVgkyOc0aCL7rRw2tzzyiveqU_C6CN_iN1wYod2jim+s-qKEw@mail.gmail.com>
	<CAHYtTqnsnO+CfYw_igvFj7pGXNKcLHZ3Fgt_tJAjv_rSuzVvsg@mail.gmail.com>
	<CAHYtTqmzFeStiBP8gPQOVU6R4Am8O4Y8cvO=Nj3G9rBsQsxhag@mail.gmail.com>
	<CABiQX1VYp-YkroBCtXK3py=Z6mxPR3gnvpk6JfaeWfF6+_=Jpw@mail.gmail.com>
	<55ED2FC4-F04D-4E13-B345-26D1EB89F32D@gmail.com>
Date: Mon, 29 Sep 2014 16:09:10 -0700
Message-ID: 
 <CAKP6k2tEJWoedrOtkNMs68dobzi05U9gx9UG39pJm09EJ=p8jw@mail.gmail.com>
Subject: Re: [DISCUSS] shrinkwrap
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b41773bbfda7d05043c5a7a

--047d7b41773bbfda7d05043c5a7a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 to pinned dependencies, and no shrinkwrap

@purplecabbage
risingj.com

On Mon, Sep 29, 2014 at 1:45 PM, Marcel Kinard <cmarcelk@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 en=
d.
>
> 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 partwa=
y
> to the destination is good enough.
>
> I did add a step to the tools release that the pinned versions get update=
d
> at the beginning of a release:
>
> https://git-wip-us.apache.org/repos/asf?p=3Dcordova-coho.git;a=3Dblobdiff=
;f=3Ddocs/tools-release-process.md;h=3D02d28c97e8dd104528035939049515338347=
c75b;hp=3Db5d288b2c5a8d3cb03bb8fc050bf26c8d15d28fb;hb=3D8ca35fe00cf0e72eb70=
d05e242fe7021ec65b028;hpb=3D14983eb014f84e08e7a76f1ab6ffe069b81f6ffa
>
> Comments?
>
> On Sep 22, 2014, at 10:01 AM, Andrew Grieve <agrieve@chromium.org> wrote:
>
> > I like having it in. For CCA, we actually did get bit in a release wher=
e
> 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 doi=
ng
> > 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.
>
>

--047d7b41773bbfda7d05043c5a7a--