cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [DISCUSS] shrinkwrap
Date Fri, 19 Sep 2014 19:18:11 GMT
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