cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [DISCUSS] shrinkwrap
Date Fri, 19 Sep 2014 17:30:17 GMT
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.

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