+ 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 <csantan...@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 <cmarc...@gmail.com> > > wrote: > > > > > > > > > > > On Sep 18, 2014, at 1:32 PM, Parashuram Narasimhan (MS OPEN TECH) < > > > > panar...@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 > > <csantan...@gmail.com> > > > -- Carlos Santana <csantan...@gmail.com>
