cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [DISCUSS] shrinkwrap
Date Mon, 22 Sep 2014 14:01:05 GMT
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.

On Fri, Sep 19, 2014 at 3:18 PM, Carlos Santana <csantana23@gmail.com>
wrote:

> kidding aside if the community feels strongly to take it out from both npm
> and git, I would respect the decision and shut up !
> I live and die by the community :-)
>
> On Fri, Sep 19, 2014 at 3:11 PM, Carlos Santana <csantana23@gmail.com>
> wrote:
>
> > It's working fine today being present in the npm package, I don't think
> we
> > should remove it just because of a "feeling"
> >
> >
> >
> > On Fri, Sep 19, 2014 at 2:51 PM, Brian LeRoux <b@brian.io> wrote:
> >
> >> ha, legal! thats why but thats not a technical reason. =)
> >>
> >> we could argue all day about subjective things like architecture but
> >> generally speaking in the node community the feeling is that shrinkwrap
> is
> >> harmful … we do not have a technical issue here, nor have we, but we do
> >> have deployment complexity and issues with shrinkwrap so I stand by the
> >> lazy consensus here that this is YAGNI
> >>
> >>
> >> On Fri, Sep 19, 2014 at 11:41 AM, Carlos Santana <csantana23@gmail.com>
> >> wrote:
> >>
> >> > + 1 leave it in npm package
> >> > + 1 take it out from git
> >> >
> >> > Technical reasons:
> >> > 1. better architecture to have all end user use the same version of
> all
> >> the
> >> > code.
> >> > 2. when we test here in ibm and install cordova from npm we know that
> >> all
> >> > testers are testing the same code,
> >> > Legal related reason:
> >> > 1. We need to create a package with cordova and all other 100 npm node
> >> > module dependencies it's easier to identify what npm package versions
> we
> >> > need to legally bless and re-distribute.
> >> >
> >> >
> >> > On Fri, Sep 19, 2014 at 2:32 PM, Brian LeRoux <b@brian.io> wrote:
> >> >
> >> > > So I think its neat we had a vote but was there a technical reason
> for
> >> > it?
> >> > > Nope. Lets kill it.
> >> > >
> >> > >
> >> > > On Fri, Sep 19, 2014 at 11:23 AM, Carlos Santana <
> >> csantana23@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > @Brian shrinkwrap was implemented in the release process because
> it
> >> was
> >> > > > discuss in the mailing list and agreed, no -1 votes
> >> > > > http://markmail.org/thread/j6bv5bk5ndlokobj
> >> > > >
> >> > > > can someone show me a jira issue or contributor having problems
> with
> >> > > having
> >> > > > npm-shrinkwrap.json in the npm package only?
> >> > > >
> >> > > >
> >> > > > On Fri, Sep 19, 2014 at 1:30 PM, Brian LeRoux <b@brian.io>
wrote:
> >> > > >
> >> > > > > I'm w/ Mike on this. No idea why we started using shrinkwrap,
> its
> >> > > always
> >> > > > > had a flaky rep, and if we don't remember why then I'm guessing
> we
> >> > > might
> >> > > > > have decided to use it for reasons that may have been more
> >> defensive
> >> > > than
> >> > > > > actually solving a problem we had. Lets turf it. If bugs
get
> >> reported
> >> > > > then
> >> > > > > we can bring it back.
> >> > > > >
> >> > > > > On Fri, Sep 19, 2014 at 9:37 AM, Marcel Kinard <
> >> cmarcelk@gmail.com>
> >> > > > wrote:
> >> > > > >
> >> > > > > >
> >> > > > > > On Sep 18, 2014, at 1:32 PM, Parashuram Narasimhan
(MS OPEN
> >> TECH) <
> >> > > > > > panarasi@microsoft.com> wrote:
> >> > > > > >
> >> > > > > > > If we do have shrinkwrap in git at all times,
who would be
> >> > > > responsible
> >> > > > > > for updating not only the versions of our dependencies,
but
> also
> >> > the
> >> > > > > > dependencies of these dependencies?
> >> > > > > >
> >> > > > > > One thought on this is that the release manager could
do it at
> >> the
> >> > > > > > beginning of a new release on master, separate from
the
> >> > > tagged/branched
> >> > > > > > release that is being packaged for release. Similar
to how we
> >> add a
> >> > > > > "-dev"
> >> > > > > > suffix, that's when there could be a systemic refresh.
And of
> >> > course,
> >> > > > if
> >> > > > > a
> >> > > > > > developer finds a technical driver to refresh the dependents
> and
> >> > > > > shrinkwrap
> >> > > > > > in the middle of a dev cycle, it would happen there
too.
> >> > > > > >
> >> > > > > > > Why should cordova-lib and cordova-plugman not
have
> >> shrinkwraps?
> >> > > Not
> >> > > > > all
> >> > > > > > tools use cordova-cli as a way to build cordova apps.
There
> were
> >> > also
> >> > > > > > discussions about using cordova-lib being the public
API to
> >> build
> >> > > apps.
> >> > > > > If
> >> > > > > > that is the case, judging by our shrinkwrap philosophy,
we
> need
> >> > that
> >> > > > file
> >> > > > > > on all repos that we say are public API.
> >> > > > > >
> >> > > > > > My thinking is that since a shrinkwrap is fully recursive,
> only
> >> the
> >> > > > > > top-level package needs to have the shrinkwrap. If
there is a
> >> > > separate
> >> > > > > > third-party app that uses cordova-lib, they can choose
whether
> >> or
> >> > not
> >> > > > to
> >> > > > > > have a shrinkwrap, and it wouldn't be partially forced
on them
> >> by
> >> > its
> >> > > > > > presence inside cordova-lib.  Well, and it's also a
pain for
> us
> >> to
> >> > > > > generate
> >> > > > > > shrinkwraps inside our own dependencies.
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Carlos Santana
> >> > > > <csantana23@gmail.com>
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Carlos Santana
> >> > <csantana23@gmail.com>
> >> >
> >>
> >
> >
> >
> > --
> > Carlos Santana
> > <csantana23@gmail.com>
> >
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message