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 agrieve@google.com designates
 209.85.214.179 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAKP6k2tEJWoedrOtkNMs68dobzi05U9gx9UG39pJm09EJ=p8jw@mail.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>
 <CAKP6k2tEJWoedrOtkNMs68dobzi05U9gx9UG39pJm09EJ=p8jw@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 30 Sep 2014 11:40:37 -0400
Message-ID: 
 <CABiQX1X36CORNQdYfv=t=saurSVenTeE_18hUQoPY-7fyUhWYA@mail.gmail.com>
Subject: Re: [DISCUSS] shrinkwrap
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c33060ae913105044a3512

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

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 <purplecabbage@gmail.com> wrote:

> +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 abou=
t
> > 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 n=
ot
> > 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=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
> where
> > we
> > > didn't have a shrinkwrap and a descendant dependency changed and brok=
e
> > > 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 th=
e
> > real
> > > problem.
> >
> >
>

--001a11c33060ae913105044a3512--