Nightly build #853 for cordova has succeeded!
The latest nightly has been published and you can try it out with 'npm i -g
cordova@nightly'
For details check build console at
https://builds.apache.org/job/cordova-nightly/853/consoleFull
-
Jenkins for Apache Cordova
-
Please review and vote on this Tools Release by replying to this email
(and keep discussion on the DISCUSS thread)
Release issue: https://github.com/apache/cordova-lib/pull/693
Minor cordova-lib@8.1.0 minor tools release packages have been
published to dist/dev:
https://dist.apache.org/repos/dist
The -nightly version is automatically published from master.
The references to user documents directory is indeed weird. This is an
artifact of how coho works. I hope we can fix this in the next major
release.
On Mon, Sep 17, 2018 at 5:22 AM Oliver Salzburg
wrote:
>
> What kind of verification is
Please review and vote on this cordova-fetch@1.3.1 tools patch release
by replying to this email (and keep discussion on the DISCUSS thread)
Release issue: https://github.com/apache/cordova-docs/pull/37
cordova-fetch@1.3.1 tools artifacts have been published to dist/dev:
https://dist.apache.org/r
I would agree with your conclusion. Except that my personal
interpretation of it was that npm is as stable as a hovercraft filled
with eels. :D
On 2018-09-17 13:22, Chris Brody wrote:
On Mon, Sep 17, 2018 at 5:35 AM Oliver Salzburg
wrote:
I would also suggest to have a brief look at the issu
The shrinkwrap *can* be a tool to have more control over the dependency
tree. But I would consider that a hack. To my understanding the
shrinkwrap is not meant to be manually edited.
In general, it is just a best practice means to lock down dependency
versions, without the negative effects of
Great, thanks!
Am Mo., 17. Sep. 2018 um 13:56 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:
> Thanks Raphael. I will likely add this information to the GitHub
> entries for the sake of extra clarification.
> On Mon, Sep 17, 2018 at 7:39 AM wrote:
> >
> > I thought it was already clear from t
Raphael I did see your argument for considering shrinkwrap once before
in [1] (seems to be buried at the end of another discussion). But then
I saw the point *not* to turn package-lock.json into npm shrinkwrap in
[2] and maybe in [3]. So I was starting to get a bit lost here.
It would be great if
Thanks Raphael. I will likely add this information to the GitHub
entries for the sake of extra clarification.
On Mon, Sep 17, 2018 at 7:39 AM wrote:
>
> I thought it was already clear from the discussion in cordova-lib#688. The
> gist is:
>
>- cordova-lib#688 is a hotfix of logic that should n
I thought it was already clear from the discussion in cordova-lib#688. The
gist is:
- cordova-lib#688 is a hotfix of logic that should never have been where
it is in the first place (from a design point of view)
- cordova-common#50 fixes the underlying problem for all users of
`supersp
I do not agree with your understanding here. We should use shrinkwrap for
all releases. Please see my _very extensive_ argument and explanation on
that topic in the thread you referenced [1].
It has all kinds of references too, some of which you then found again
yourself in a later message of the
On Mon, Sep 17, 2018 at 5:35 AM Oliver Salzburg
wrote:
>
> I would also suggest to have a brief look at the issues other users are
> reporting regarding this:
>
> - https://github.com/npm/npm/issues?utf8=%E2%9C%93&q=is%3Aissue+package-lock
> - https://npm.community/search?q=package-lock%20category
Originated in another thread ([1]), moving into a new thread.
My understanding is that we should only do npm shrinkwrap if needed to
deal with a dependency problem in an end-user package such as
cordova-cli.
I would like to ask people to please use references whenever possible.
[1]
https://list
Hi Raphael,
I gotta say I don't understand a couple things:
* cordova-lib #688
* why fix it in cordova-lib in a patch one day then fix it in
cordova-common another day
The changes cordova-lib#688 do see to be similar (using which for
win32) to code that is actually replaced in cordova-common#50.
+1 to shrinkwrap before publish
On 2018-09-15 00:27, raphine...@gmail.com wrote:
Please note that I'm not suggesting to commit shrinkwrap to the master of
every repository. That is what had been discussed in the mailing list
thread from 2014 that you shared. That option was dismissed then, and
r
I would also suggest to have a brief look at the issues other users are
reporting regarding this:
- https://github.com/npm/npm/issues?utf8=%E2%9C%93&q=is%3Aissue+package-lock
- https://npm.community/search?q=package-lock%20category%3A6
Of course, in the end, nothing beats a validation against o
What kind of verification is expected for these types of changes?
#285 only adds a license header. That looks pretty safe to me.
#287 I have a hard time seeing any relevant changes either. The
references to C:/Users/brodybits/Documents seem weird.
#281 seems to be the only relevant change at a
17 matches
Mail list logo
