Nightly build #850 for cordova has succeeded!

[Apache Jenkins Server]

Nightly build #850 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/850/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Commit package-lock.json in next major Cordova release or not?

[Jesse]

+1
Thank you for the clarity! I am completely supportive of this.

@purplecabbage
risingj.com


On Fri, Sep 14, 2018 at 3:28 PM  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
> rightly so. It is also strongly advised against in the npm docs.
>
> I suggest using it only in release branches of CLI or other non-library
> releases, so they are immutable and don't mutate over time. _This is
> exactly the intended use_. And it comes at no cost other than having to run
> `npm shrinkwrap` right before the release.
>
> Plus, it allows us to override transitive dependency versions for a release
> if absolutely necessary.
>
> Am Sa., 15. Sep. 2018 um 00:16 Uhr schrieb Jesse  >:
>
> > I personally see shrinkwrap as a step in the wrong direction, I feel like
> > it has been explored in the past, and the general consensus is that it is
> > something to avoid.
> > If committing package-lock is contentious, I am okay with skipping it,
> but
> > we need to be careful to lock down our own dependencies and not use
> > wildcards.
> >
> > We have flexibility in our current GitHub repos, which allow us to remix
> > and freely link other dependent packages so we can debug right through
> our
> > deps.  I agree we need more stability around the release/publish steps so
> > we can move more quickly through the collection of packages that make up
> a
> > 'tools' release.
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Fri, Sep 14, 2018 at 2:56 PM  wrote:
> >
> > > No. This won't fix anything. Plus it goes directly against npm's
> > > recommendation. Please double check the docs for the use cases of
> > > package-lock.json vs npm-shrinkwrap.json.
> > >
> > > Am Fr., 14. Sep. 2018 um 23:48 Uhr schrieb Chris Brody <
> > > chris.br...@gmail.com>:
> > >
> > > > A really nice alternative may be to turn the generated
> > > > package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
> > > > command) then commit npm-shrinkwrap.json. Then I think any other npm
> > > > install updates would update npm-shrinkwrap.json instead of
> > > > package-lock.json. Could be more predictable and easier to
> understand.
> > > >
> > > > This was already discussed in 2014 [1], thanks to Jesse for the link
> in
> > > > [2].
> > > >
> > > > Thanks for the suggestion to use npm shrinkwrap as a solution for
> > > > cordova-cli 8.1.0 minor release in [2].
> > > >
> > > > [1]
> > > >
> > >
> >
> https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E
> > > >
> > > > [2]
> > > >
> > >
> >
> https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E
> > > > On Fri, Sep 14, 2018 at 3:53 PM Chris Brody 
> > > wrote:
> > > > >
> > > > > To be honest I have pretty limited experience with package lock
> file
> > > > > and it is now starting to show. From Oliver's very unfortunate
> > > > > experience I would conclude that this is something we should do
> very
> > > > > carefully and not just on a whim. Some things I can think of:
> > > > >
> > > > > * always use recent version of npm such as npm@6.4.1 to generate
> or
> > > > > update package-lock.json
> > > > > * do not use. npm cache when generating or updating
> > package-lock.json,
> > > > > or use the npm cache with extreme care (also limited experience for
> > > > > me)
> > > > > * be extremely careful with assumptions; I think we should both
> > > > > double-check the documentation and do our own experimentation,
> like I
> > > > > did in  to
> validate
> > as
> > > > > best we can
> > > > > * semver package seems to be a major library package used by npm;
> we
> > > > > should both read the documentation and experiment, ideally with its
> > > > > own test cases
> > > > >
> > > > > On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
> > > > >  wrote:
> > > > > >
> > > > > > The problems that appear when you have linked dependencies is
> that
> > > npm
> > > > > > will pick them up as being bundled and mark them as such in the
> > > > > > lockfile. *However* this behavior has changed in the past. At one
> > > point
> > > > > > this affected any direct dependency, at another point it "only"
> > > > affected
> > > > > > dependencies of dependencies.
> > > > > >
> > > > > > Either way, the result is:
> > > > > >
> > > > > > a) a corrupted lockfile, which has dependencies marked as bundled
> > > > > > b) a lockfile that lists incorrect versions, resulting from
> linking
> > > > > > temporary development snapshots together
> > > > > >
> > > > > > When you use a local npm cache and you neglected to correctly
> > > > > > parameterize your npm calls, you now have your custom registry
> URL
> > in
> > > > > > the lockfile for every package it 

Re: Commit package-lock.json in next major Cordova release or not?

[raphinesse]

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
rightly so. It is also strongly advised against in the npm docs.

I suggest using it only in release branches of CLI or other non-library
releases, so they are immutable and don't mutate over time. _This is
exactly the intended use_. And it comes at no cost other than having to run
`npm shrinkwrap` right before the release.

Plus, it allows us to override transitive dependency versions for a release
if absolutely necessary.

Am Sa., 15. Sep. 2018 um 00:16 Uhr schrieb Jesse :

> I personally see shrinkwrap as a step in the wrong direction, I feel like
> it has been explored in the past, and the general consensus is that it is
> something to avoid.
> If committing package-lock is contentious, I am okay with skipping it, but
> we need to be careful to lock down our own dependencies and not use
> wildcards.
>
> We have flexibility in our current GitHub repos, which allow us to remix
> and freely link other dependent packages so we can debug right through our
> deps.  I agree we need more stability around the release/publish steps so
> we can move more quickly through the collection of packages that make up a
> 'tools' release.
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Sep 14, 2018 at 2:56 PM  wrote:
>
> > No. This won't fix anything. Plus it goes directly against npm's
> > recommendation. Please double check the docs for the use cases of
> > package-lock.json vs npm-shrinkwrap.json.
> >
> > Am Fr., 14. Sep. 2018 um 23:48 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> >
> > > A really nice alternative may be to turn the generated
> > > package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
> > > command) then commit npm-shrinkwrap.json. Then I think any other npm
> > > install updates would update npm-shrinkwrap.json instead of
> > > package-lock.json. Could be more predictable and easier to understand.
> > >
> > > This was already discussed in 2014 [1], thanks to Jesse for the link in
> > > [2].
> > >
> > > Thanks for the suggestion to use npm shrinkwrap as a solution for
> > > cordova-cli 8.1.0 minor release in [2].
> > >
> > > [1]
> > >
> >
> https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E
> > >
> > > [2]
> > >
> >
> https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E
> > > On Fri, Sep 14, 2018 at 3:53 PM Chris Brody 
> > wrote:
> > > >
> > > > To be honest I have pretty limited experience with package lock file
> > > > and it is now starting to show. From Oliver's very unfortunate
> > > > experience I would conclude that this is something we should do very
> > > > carefully and not just on a whim. Some things I can think of:
> > > >
> > > > * always use recent version of npm such as npm@6.4.1 to generate or
> > > > update package-lock.json
> > > > * do not use. npm cache when generating or updating
> package-lock.json,
> > > > or use the npm cache with extreme care (also limited experience for
> > > > me)
> > > > * be extremely careful with assumptions; I think we should both
> > > > double-check the documentation and do our own experimentation, like I
> > > > did in  to validate
> as
> > > > best we can
> > > > * semver package seems to be a major library package used by npm; we
> > > > should both read the documentation and experiment, ideally with its
> > > > own test cases
> > > >
> > > > On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
> > > >  wrote:
> > > > >
> > > > > The problems that appear when you have linked dependencies is that
> > npm
> > > > > will pick them up as being bundled and mark them as such in the
> > > > > lockfile. *However* this behavior has changed in the past. At one
> > point
> > > > > this affected any direct dependency, at another point it "only"
> > > affected
> > > > > dependencies of dependencies.
> > > > >
> > > > > Either way, the result is:
> > > > >
> > > > > a) a corrupted lockfile, which has dependencies marked as bundled
> > > > > b) a lockfile that lists incorrect versions, resulting from linking
> > > > > temporary development snapshots together
> > > > >
> > > > > When you use a local npm cache and you neglected to correctly
> > > > > parameterize your npm calls, you now have your custom registry URL
> in
> > > > > the lockfile for every package it installed from there. This makes
> it
> > > > > unusable for others.
> > > > >
> > > > > The issue that ultimately drove us away from this concept was that
> > > > > locally cached packages were installed over linked modules, because
> > the
> > > > > package manager did not understand that they are linked.
> > > > > But because they were linked, the cached package contents were
> 

Re: Commit package-lock.json in next major Cordova release or not?

[Jesse]

I personally see shrinkwrap as a step in the wrong direction, I feel like
it has been explored in the past, and the general consensus is that it is
something to avoid.
If committing package-lock is contentious, I am okay with skipping it, but
we need to be careful to lock down our own dependencies and not use
wildcards.

We have flexibility in our current GitHub repos, which allow us to remix
and freely link other dependent packages so we can debug right through our
deps.  I agree we need more stability around the release/publish steps so
we can move more quickly through the collection of packages that make up a
'tools' release.

@purplecabbage
risingj.com


On Fri, Sep 14, 2018 at 2:56 PM  wrote:

> No. This won't fix anything. Plus it goes directly against npm's
> recommendation. Please double check the docs for the use cases of
> package-lock.json vs npm-shrinkwrap.json.
>
> Am Fr., 14. Sep. 2018 um 23:48 Uhr schrieb Chris Brody <
> chris.br...@gmail.com>:
>
> > A really nice alternative may be to turn the generated
> > package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
> > command) then commit npm-shrinkwrap.json. Then I think any other npm
> > install updates would update npm-shrinkwrap.json instead of
> > package-lock.json. Could be more predictable and easier to understand.
> >
> > This was already discussed in 2014 [1], thanks to Jesse for the link in
> > [2].
> >
> > Thanks for the suggestion to use npm shrinkwrap as a solution for
> > cordova-cli 8.1.0 minor release in [2].
> >
> > [1]
> >
> https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E
> >
> > [2]
> >
> https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E
> > On Fri, Sep 14, 2018 at 3:53 PM Chris Brody 
> wrote:
> > >
> > > To be honest I have pretty limited experience with package lock file
> > > and it is now starting to show. From Oliver's very unfortunate
> > > experience I would conclude that this is something we should do very
> > > carefully and not just on a whim. Some things I can think of:
> > >
> > > * always use recent version of npm such as npm@6.4.1 to generate or
> > > update package-lock.json
> > > * do not use. npm cache when generating or updating package-lock.json,
> > > or use the npm cache with extreme care (also limited experience for
> > > me)
> > > * be extremely careful with assumptions; I think we should both
> > > double-check the documentation and do our own experimentation, like I
> > > did in  to validate as
> > > best we can
> > > * semver package seems to be a major library package used by npm; we
> > > should both read the documentation and experiment, ideally with its
> > > own test cases
> > >
> > > On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
> > >  wrote:
> > > >
> > > > The problems that appear when you have linked dependencies is that
> npm
> > > > will pick them up as being bundled and mark them as such in the
> > > > lockfile. *However* this behavior has changed in the past. At one
> point
> > > > this affected any direct dependency, at another point it "only"
> > affected
> > > > dependencies of dependencies.
> > > >
> > > > Either way, the result is:
> > > >
> > > > a) a corrupted lockfile, which has dependencies marked as bundled
> > > > b) a lockfile that lists incorrect versions, resulting from linking
> > > > temporary development snapshots together
> > > >
> > > > When you use a local npm cache and you neglected to correctly
> > > > parameterize your npm calls, you now have your custom registry URL in
> > > > the lockfile for every package it installed from there. This makes it
> > > > unusable for others.
> > > >
> > > > The issue that ultimately drove us away from this concept was that
> > > > locally cached packages were installed over linked modules, because
> the
> > > > package manager did not understand that they are linked.
> > > > But because they were linked, the cached package contents were placed
> > in
> > > > my local development checkout of that linked module. That obviously
> > > > caused all uncommitted changes to be deleted.
> > > >
> > > > Additionally, if you already have linked modules set up, but the
> > > > lockfile says that a certain dependency is to be replaced, it will
> just
> > > > break your link or replace your linked code as soon as you `npm
> > install`.
> > > >
> > > > We had so many issues with this, I'm sure I'm only remembering the
> tip
> > > > of the ice berg. Maybe all of this was fixed somehow, but I doubt it.
> > At
> > > > the time when I reported these issues, there was little interest in
> > > > resolving them.
> > > >
> > > > However, I'm not unfamiliar with the lockfile-driven workflow as many
> > > > OSS projects I contributed to use it. It is not uncommon to
> completely
> > > > wipe your node_modules and/or package-lock.json to 

Re: Commit package-lock.json in next major Cordova release or not?

[raphinesse]

No. This won't fix anything. Plus it goes directly against npm's
recommendation. Please double check the docs for the use cases of
package-lock.json vs npm-shrinkwrap.json.

Am Fr., 14. Sep. 2018 um 23:48 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:

> A really nice alternative may be to turn the generated
> package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
> command) then commit npm-shrinkwrap.json. Then I think any other npm
> install updates would update npm-shrinkwrap.json instead of
> package-lock.json. Could be more predictable and easier to understand.
>
> This was already discussed in 2014 [1], thanks to Jesse for the link in
> [2].
>
> Thanks for the suggestion to use npm shrinkwrap as a solution for
> cordova-cli 8.1.0 minor release in [2].
>
> [1]
> https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E
>
> [2]
> https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E
> On Fri, Sep 14, 2018 at 3:53 PM Chris Brody  wrote:
> >
> > To be honest I have pretty limited experience with package lock file
> > and it is now starting to show. From Oliver's very unfortunate
> > experience I would conclude that this is something we should do very
> > carefully and not just on a whim. Some things I can think of:
> >
> > * always use recent version of npm such as npm@6.4.1 to generate or
> > update package-lock.json
> > * do not use. npm cache when generating or updating package-lock.json,
> > or use the npm cache with extreme care (also limited experience for
> > me)
> > * be extremely careful with assumptions; I think we should both
> > double-check the documentation and do our own experimentation, like I
> > did in  to validate as
> > best we can
> > * semver package seems to be a major library package used by npm; we
> > should both read the documentation and experiment, ideally with its
> > own test cases
> >
> > On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
> >  wrote:
> > >
> > > The problems that appear when you have linked dependencies is that npm
> > > will pick them up as being bundled and mark them as such in the
> > > lockfile. *However* this behavior has changed in the past. At one point
> > > this affected any direct dependency, at another point it "only"
> affected
> > > dependencies of dependencies.
> > >
> > > Either way, the result is:
> > >
> > > a) a corrupted lockfile, which has dependencies marked as bundled
> > > b) a lockfile that lists incorrect versions, resulting from linking
> > > temporary development snapshots together
> > >
> > > When you use a local npm cache and you neglected to correctly
> > > parameterize your npm calls, you now have your custom registry URL in
> > > the lockfile for every package it installed from there. This makes it
> > > unusable for others.
> > >
> > > The issue that ultimately drove us away from this concept was that
> > > locally cached packages were installed over linked modules, because the
> > > package manager did not understand that they are linked.
> > > But because they were linked, the cached package contents were placed
> in
> > > my local development checkout of that linked module. That obviously
> > > caused all uncommitted changes to be deleted.
> > >
> > > Additionally, if you already have linked modules set up, but the
> > > lockfile says that a certain dependency is to be replaced, it will just
> > > break your link or replace your linked code as soon as you `npm
> install`.
> > >
> > > We had so many issues with this, I'm sure I'm only remembering the tip
> > > of the ice berg. Maybe all of this was fixed somehow, but I doubt it.
> At
> > > the time when I reported these issues, there was little interest in
> > > resolving them.
> > >
> > > However, I'm not unfamiliar with the lockfile-driven workflow as many
> > > OSS projects I contributed to use it. It is not uncommon to completely
> > > wipe your node_modules and/or package-lock.json to rebuild it, because
> > > of corruptions in either entity. And that is something that has been
> > > confirmed to me many times by other developers. As in "That's just how
> > > it is."
> > >
> > > This entire area of issues was not exclusive to npm either. We
> > > extensively evaluated yarn regarding these aspects and it performed
> just
> > > as poorly.
> > >
> > > I consider these aspects unacceptable for a development workflow as
> they
> > > introduce an unreliability where I can't have one.
> > >
> > > If someone came out and told me "Hey, you've been doing it wrong all
> > > along. These are your mistakes and this is how you resolve them." then
> > > I'd be very happy to hear that :)
> > >
> > > On 2018-09-14 15:13, raphine...@gmail.com wrote:
> > > > Thanks for picking this up again Chris. I think now is a better time
> for
> > > > second thoughts than later.
> > > >
> > > > 

Re: Commit package-lock.json in next major Cordova release or not?

[Chris Brody]

A really nice alternative may be to turn the generated
package-lock.json into npm-shrinkwrap.json (using npm shrinkwrap
command) then commit npm-shrinkwrap.json. Then I think any other npm
install updates would update npm-shrinkwrap.json instead of
package-lock.json. Could be more predictable and easier to understand.

This was already discussed in 2014 [1], thanks to Jesse for the link in [2].

Thanks for the suggestion to use npm shrinkwrap as a solution for
cordova-cli 8.1.0 minor release in [2].

[1] 
https://lists.apache.org/thread.html/99184622129935eb473e843e583bf6648faff279a014e8508cc2c660@1411013202@%3Cdev.cordova.apache.org%3E

[2] 
https://lists.apache.org/thread.html/f89a074add24f2ace7006b0211cf43a47cc5c1a0a65932fc22515828@%3Cdev.cordova.apache.org%3E
On Fri, Sep 14, 2018 at 3:53 PM Chris Brody  wrote:
>
> To be honest I have pretty limited experience with package lock file
> and it is now starting to show. From Oliver's very unfortunate
> experience I would conclude that this is something we should do very
> carefully and not just on a whim. Some things I can think of:
>
> * always use recent version of npm such as npm@6.4.1 to generate or
> update package-lock.json
> * do not use. npm cache when generating or updating package-lock.json,
> or use the npm cache with extreme care (also limited experience for
> me)
> * be extremely careful with assumptions; I think we should both
> double-check the documentation and do our own experimentation, like I
> did in  to validate as
> best we can
> * semver package seems to be a major library package used by npm; we
> should both read the documentation and experiment, ideally with its
> own test cases
>
> On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
>  wrote:
> >
> > The problems that appear when you have linked dependencies is that npm
> > will pick them up as being bundled and mark them as such in the
> > lockfile. *However* this behavior has changed in the past. At one point
> > this affected any direct dependency, at another point it "only" affected
> > dependencies of dependencies.
> >
> > Either way, the result is:
> >
> > a) a corrupted lockfile, which has dependencies marked as bundled
> > b) a lockfile that lists incorrect versions, resulting from linking
> > temporary development snapshots together
> >
> > When you use a local npm cache and you neglected to correctly
> > parameterize your npm calls, you now have your custom registry URL in
> > the lockfile for every package it installed from there. This makes it
> > unusable for others.
> >
> > The issue that ultimately drove us away from this concept was that
> > locally cached packages were installed over linked modules, because the
> > package manager did not understand that they are linked.
> > But because they were linked, the cached package contents were placed in
> > my local development checkout of that linked module. That obviously
> > caused all uncommitted changes to be deleted.
> >
> > Additionally, if you already have linked modules set up, but the
> > lockfile says that a certain dependency is to be replaced, it will just
> > break your link or replace your linked code as soon as you `npm install`.
> >
> > We had so many issues with this, I'm sure I'm only remembering the tip
> > of the ice berg. Maybe all of this was fixed somehow, but I doubt it. At
> > the time when I reported these issues, there was little interest in
> > resolving them.
> >
> > However, I'm not unfamiliar with the lockfile-driven workflow as many
> > OSS projects I contributed to use it. It is not uncommon to completely
> > wipe your node_modules and/or package-lock.json to rebuild it, because
> > of corruptions in either entity. And that is something that has been
> > confirmed to me many times by other developers. As in "That's just how
> > it is."
> >
> > This entire area of issues was not exclusive to npm either. We
> > extensively evaluated yarn regarding these aspects and it performed just
> > as poorly.
> >
> > I consider these aspects unacceptable for a development workflow as they
> > introduce an unreliability where I can't have one.
> >
> > If someone came out and told me "Hey, you've been doing it wrong all
> > along. These are your mistakes and this is how you resolve them." then
> > I'd be very happy to hear that :)
> >
> > On 2018-09-14 15:13, raphine...@gmail.com wrote:
> > > Thanks for picking this up again Chris. I think now is a better time for
> > > second thoughts than later.
> > >
> > > I've had a look at your experiment and the behavior you observed is to be
> > > expected and desirable, as I explained in more detail in a comment [1]
> > > there. As I also mentioned there, deleting and regenerating 
> > > package-lock.json
> > > is a valid approach _if and when_ you want to do a full dependency update,
> > > as we regularly do.
> > >
> > > Also, thanks for posting Oliver's message here for better visibility in
> > > this discussion. 

Re: Cordova 8.1.0 (minor release) proposal

[Jesse]

Here's a similar discussion on the relative merits of shrinkwrap from 2014.
https://markmail.org/thread/osbvx53d3l5s6fsj


@purplecabbage
risingj.com




On Fri, Sep 14, 2018 at 2:04 PM Chris Brody  wrote:

> A quick try of #6 worked for me, you can see the results in my
> cordova-cli WIP PR at: https://github.com/apache/cordova-cli/pull/326
>
> It is probably not the best: I simply edited npm-shrinkwrap.json by
> hand, then npm install would update it further.
>
> Resolves npm audit issues, runs on Node.js 4, does not need possibly
> breaking change from insight@0.10.x.
>
> I will try to do a better job next week, at least we know #6 is possible.
> On Fri, Sep 14, 2018 at 4:52 PM  wrote:
> >
> > I'd really like to try #6. If that does not work as expected, we can
> still
> > go with #2.
> >
> > Jan Piotrowski  schrieb am Fr., 14. Sep. 2018,
> 21:47:
> >
> > > #2 sounds absolutely fine to me as this dependency is in cordova-cli
> > > which is only used on developer machines, not included in any deployed
> > > packages.
> > >
> > > Besides: Cordova has been shipping software with `npm audit` like
> > > issues for ages and I don't think there has been a "totally
> > > unacceptable in all cases" vote result on that.
> > >
> > > -J
> > >
> > > 2018-09-14 21:31 GMT+02:00  :
> > > > 6. Use manually edited npm-shrinkwrap.json to force a more recent
> version
> > > > of `inquirer` ourselves. Little work, no audit warnings for the
> users. I
> > > > could do that when the branch is ready. However, we should test the
> whole
> > > > thing with a alpha suffix or something like that first.
> > > >
> > > > Am Fr., 14. Sep. 2018 um 21:18 Uhr schrieb Chris Brody <
> > > > chris.br...@gmail.com>:
> > > >
> > > >> Unfortunately I spotted a catch-22 situation while working on CLI
> > > >> 8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
> > > >> * insight@0.8 (0.8.4) has the audit issue
> > > >> * newer insight starting with 0.9 uses inquirer@5 which does not
> > > >> support Node.js 4.
> > > >>
> > > >> I can think of the following alternatives:
> > > >>
> > > >> 1. skip the proposed 8.1.0 minor release
> > > >> 2. publish 8.1.0 minor release with known audit issue in the CLI
> > > >> 3. drop use of insight in 8.1.0 minor release
> > > >> 4. ask insight to publish 0.8.5 release that resolves the audit
> issue
> > > >> 5. publish special fork of insight which resolves the audit issue
> for
> > > >> 8.1.0 minor release
> > > >>
> > > >> Disadvantages of each alternative:
> > > >>
> > > >> 1: Users do not get some needed updates before the next major
> release.
> > > >> I think the major ones are:
> > > >> - use of cordova-android@~7.1.x by default
> > > >> - use of cordova-windows@~6.0.x by default
> > > >>
> > > >> 2: Bad practice, with possible responsibility for unknown security
> > > >> issues. While I would not expect any real security issues in
> practice,
> > > >> I would say better safe than sorry.
> > > >>
> > > >> 3. I think this kind of behavior should not be dropped in minor
> > > >> release, only to come back in next major release.
> > > >>
> > > >> 4. I highly doubt they would be motivated to do such a thing for us.
> > > >> Support for deprecated Node.js 4 is not desired in other projects
> > > >> unless absolutely necessary.
> > > >>
> > > >> 5. One more package for us to manage and maintain, on a temporary
> basis
> > > >>
> > > >> To be honest I really wouldn't mind if we would just make the new
> > > >> release to drop Node.js 4 support and abandon support for the
> existing
> > > >> package releases.
> > > >> On Fri, Sep 14, 2018 at 9:25 AM  wrote:
> > > >> >
> > > >> > Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
> > > >> > chris.br...@gmail.com>:
> > > >> >
> > > >> > > Thanks Raphael for the reminder about insight, which I
> overlooked. I
> > > >> > > personally do not like the idea of an extra reminder message
> before
> > > the
> > > >> > > next major release. I would like to consider this over the
> weekend
> > > >> > >
> > > >> >
> > > >> > That could be resolved in a few ways:
> > > >> >
> > > >> >- rolling back to previous version (can't remember if it had
> audit
> > > >> >issues)
> > > >> >- Using insight's `config` option [1] with a config provider
> that
> > > uses
> > > >> >the same file as before. The commit that changed the config
> store
> > > was
> > > >> [2]
> > > >> >
> > > >> > Cheers
> > > >> >
> > > >> > [1]: https://github.com/yeoman/insight#config
> > > >> > [2]:
> > > >> >
> > > >>
> > >
> https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: 

Re: Cordova 8.1.0 (minor release) proposal

[Chris Brody]

A quick try of #6 worked for me, you can see the results in my
cordova-cli WIP PR at: https://github.com/apache/cordova-cli/pull/326

It is probably not the best: I simply edited npm-shrinkwrap.json by
hand, then npm install would update it further.

Resolves npm audit issues, runs on Node.js 4, does not need possibly
breaking change from insight@0.10.x.

I will try to do a better job next week, at least we know #6 is possible.
On Fri, Sep 14, 2018 at 4:52 PM  wrote:
>
> I'd really like to try #6. If that does not work as expected, we can still
> go with #2.
>
> Jan Piotrowski  schrieb am Fr., 14. Sep. 2018, 21:47:
>
> > #2 sounds absolutely fine to me as this dependency is in cordova-cli
> > which is only used on developer machines, not included in any deployed
> > packages.
> >
> > Besides: Cordova has been shipping software with `npm audit` like
> > issues for ages and I don't think there has been a "totally
> > unacceptable in all cases" vote result on that.
> >
> > -J
> >
> > 2018-09-14 21:31 GMT+02:00  :
> > > 6. Use manually edited npm-shrinkwrap.json to force a more recent version
> > > of `inquirer` ourselves. Little work, no audit warnings for the users. I
> > > could do that when the branch is ready. However, we should test the whole
> > > thing with a alpha suffix or something like that first.
> > >
> > > Am Fr., 14. Sep. 2018 um 21:18 Uhr schrieb Chris Brody <
> > > chris.br...@gmail.com>:
> > >
> > >> Unfortunately I spotted a catch-22 situation while working on CLI
> > >> 8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
> > >> * insight@0.8 (0.8.4) has the audit issue
> > >> * newer insight starting with 0.9 uses inquirer@5 which does not
> > >> support Node.js 4.
> > >>
> > >> I can think of the following alternatives:
> > >>
> > >> 1. skip the proposed 8.1.0 minor release
> > >> 2. publish 8.1.0 minor release with known audit issue in the CLI
> > >> 3. drop use of insight in 8.1.0 minor release
> > >> 4. ask insight to publish 0.8.5 release that resolves the audit issue
> > >> 5. publish special fork of insight which resolves the audit issue for
> > >> 8.1.0 minor release
> > >>
> > >> Disadvantages of each alternative:
> > >>
> > >> 1: Users do not get some needed updates before the next major release.
> > >> I think the major ones are:
> > >> - use of cordova-android@~7.1.x by default
> > >> - use of cordova-windows@~6.0.x by default
> > >>
> > >> 2: Bad practice, with possible responsibility for unknown security
> > >> issues. While I would not expect any real security issues in practice,
> > >> I would say better safe than sorry.
> > >>
> > >> 3. I think this kind of behavior should not be dropped in minor
> > >> release, only to come back in next major release.
> > >>
> > >> 4. I highly doubt they would be motivated to do such a thing for us.
> > >> Support for deprecated Node.js 4 is not desired in other projects
> > >> unless absolutely necessary.
> > >>
> > >> 5. One more package for us to manage and maintain, on a temporary basis
> > >>
> > >> To be honest I really wouldn't mind if we would just make the new
> > >> release to drop Node.js 4 support and abandon support for the existing
> > >> package releases.
> > >> On Fri, Sep 14, 2018 at 9:25 AM  wrote:
> > >> >
> > >> > Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
> > >> > chris.br...@gmail.com>:
> > >> >
> > >> > > Thanks Raphael for the reminder about insight, which I overlooked. I
> > >> > > personally do not like the idea of an extra reminder message before
> > the
> > >> > > next major release. I would like to consider this over the weekend
> > >> > >
> > >> >
> > >> > That could be resolved in a few ways:
> > >> >
> > >> >- rolling back to previous version (can't remember if it had audit
> > >> >issues)
> > >> >- Using insight's `config` option [1] with a config provider that
> > uses
> > >> >the same file as before. The commit that changed the config store
> > was
> > >> [2]
> > >> >
> > >> > Cheers
> > >> >
> > >> > [1]: https://github.com/yeoman/insight#config
> > >> > [2]:
> > >> >
> > >>
> > https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 8.1.0 (minor release) proposal

[raphinesse]

I'd really like to try #6. If that does not work as expected, we can still
go with #2.

Jan Piotrowski  schrieb am Fr., 14. Sep. 2018, 21:47:

> #2 sounds absolutely fine to me as this dependency is in cordova-cli
> which is only used on developer machines, not included in any deployed
> packages.
>
> Besides: Cordova has been shipping software with `npm audit` like
> issues for ages and I don't think there has been a "totally
> unacceptable in all cases" vote result on that.
>
> -J
>
> 2018-09-14 21:31 GMT+02:00  :
> > 6. Use manually edited npm-shrinkwrap.json to force a more recent version
> > of `inquirer` ourselves. Little work, no audit warnings for the users. I
> > could do that when the branch is ready. However, we should test the whole
> > thing with a alpha suffix or something like that first.
> >
> > Am Fr., 14. Sep. 2018 um 21:18 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> >
> >> Unfortunately I spotted a catch-22 situation while working on CLI
> >> 8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
> >> * insight@0.8 (0.8.4) has the audit issue
> >> * newer insight starting with 0.9 uses inquirer@5 which does not
> >> support Node.js 4.
> >>
> >> I can think of the following alternatives:
> >>
> >> 1. skip the proposed 8.1.0 minor release
> >> 2. publish 8.1.0 minor release with known audit issue in the CLI
> >> 3. drop use of insight in 8.1.0 minor release
> >> 4. ask insight to publish 0.8.5 release that resolves the audit issue
> >> 5. publish special fork of insight which resolves the audit issue for
> >> 8.1.0 minor release
> >>
> >> Disadvantages of each alternative:
> >>
> >> 1: Users do not get some needed updates before the next major release.
> >> I think the major ones are:
> >> - use of cordova-android@~7.1.x by default
> >> - use of cordova-windows@~6.0.x by default
> >>
> >> 2: Bad practice, with possible responsibility for unknown security
> >> issues. While I would not expect any real security issues in practice,
> >> I would say better safe than sorry.
> >>
> >> 3. I think this kind of behavior should not be dropped in minor
> >> release, only to come back in next major release.
> >>
> >> 4. I highly doubt they would be motivated to do such a thing for us.
> >> Support for deprecated Node.js 4 is not desired in other projects
> >> unless absolutely necessary.
> >>
> >> 5. One more package for us to manage and maintain, on a temporary basis
> >>
> >> To be honest I really wouldn't mind if we would just make the new
> >> release to drop Node.js 4 support and abandon support for the existing
> >> package releases.
> >> On Fri, Sep 14, 2018 at 9:25 AM  wrote:
> >> >
> >> > Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
> >> > chris.br...@gmail.com>:
> >> >
> >> > > Thanks Raphael for the reminder about insight, which I overlooked. I
> >> > > personally do not like the idea of an extra reminder message before
> the
> >> > > next major release. I would like to consider this over the weekend
> >> > >
> >> >
> >> > That could be resolved in a few ways:
> >> >
> >> >- rolling back to previous version (can't remember if it had audit
> >> >issues)
> >> >- Using insight's `config` option [1] with a config provider that
> uses
> >> >the same file as before. The commit that changed the config store
> was
> >> [2]
> >> >
> >> > Cheers
> >> >
> >> > [1]: https://github.com/yeoman/insight#config
> >> > [2]:
> >> >
> >>
> https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Commit package-lock.json in next major Cordova release or not?

[Chris Brody]

To be honest I have pretty limited experience with package lock file
and it is now starting to show. From Oliver's very unfortunate
experience I would conclude that this is something we should do very
carefully and not just on a whim. Some things I can think of:

* always use recent version of npm such as npm@6.4.1 to generate or
update package-lock.json
* do not use. npm cache when generating or updating package-lock.json,
or use the npm cache with extreme care (also limited experience for
me)
* be extremely careful with assumptions; I think we should both
double-check the documentation and do our own experimentation, like I
did in  to validate as
best we can
* semver package seems to be a major library package used by npm; we
should both read the documentation and experiment, ideally with its
own test cases

On Fri, Sep 14, 2018 at 9:47 AM Oliver Salzburg
 wrote:
>
> The problems that appear when you have linked dependencies is that npm
> will pick them up as being bundled and mark them as such in the
> lockfile. *However* this behavior has changed in the past. At one point
> this affected any direct dependency, at another point it "only" affected
> dependencies of dependencies.
>
> Either way, the result is:
>
> a) a corrupted lockfile, which has dependencies marked as bundled
> b) a lockfile that lists incorrect versions, resulting from linking
> temporary development snapshots together
>
> When you use a local npm cache and you neglected to correctly
> parameterize your npm calls, you now have your custom registry URL in
> the lockfile for every package it installed from there. This makes it
> unusable for others.
>
> The issue that ultimately drove us away from this concept was that
> locally cached packages were installed over linked modules, because the
> package manager did not understand that they are linked.
> But because they were linked, the cached package contents were placed in
> my local development checkout of that linked module. That obviously
> caused all uncommitted changes to be deleted.
>
> Additionally, if you already have linked modules set up, but the
> lockfile says that a certain dependency is to be replaced, it will just
> break your link or replace your linked code as soon as you `npm install`.
>
> We had so many issues with this, I'm sure I'm only remembering the tip
> of the ice berg. Maybe all of this was fixed somehow, but I doubt it. At
> the time when I reported these issues, there was little interest in
> resolving them.
>
> However, I'm not unfamiliar with the lockfile-driven workflow as many
> OSS projects I contributed to use it. It is not uncommon to completely
> wipe your node_modules and/or package-lock.json to rebuild it, because
> of corruptions in either entity. And that is something that has been
> confirmed to me many times by other developers. As in "That's just how
> it is."
>
> This entire area of issues was not exclusive to npm either. We
> extensively evaluated yarn regarding these aspects and it performed just
> as poorly.
>
> I consider these aspects unacceptable for a development workflow as they
> introduce an unreliability where I can't have one.
>
> If someone came out and told me "Hey, you've been doing it wrong all
> along. These are your mistakes and this is how you resolve them." then
> I'd be very happy to hear that :)
>
> On 2018-09-14 15:13, raphine...@gmail.com wrote:
> > Thanks for picking this up again Chris. I think now is a better time for
> > second thoughts than later.
> >
> > I've had a look at your experiment and the behavior you observed is to be
> > expected and desirable, as I explained in more detail in a comment [1]
> > there. As I also mentioned there, deleting and regenerating 
> > package-lock.json
> > is a valid approach _if and when_ you want to do a full dependency update,
> > as we regularly do.
> >
> > Also, thanks for posting Oliver's message here for better visibility in
> > this discussion. What I _do_ find a bit disturbing is the problems he
> > mentioned regarding linking (as in `npm link`) of different modules which
> > are all using lock files. He expressed his concern regarding that
> > particular use-case again in a comment [2] of a PR where we touched that
> > topic. I think it is important we test this, since the ability to link
> > modules is vital for our development workflow and I have no experience with
> > package-lock.json in projects where a lot of linking is necessary.
> >
> > Finally, I think we might need to re-evaluate our presumed knowledge about
> > the topic at hand. I encourage all those interested to read [3][4][5] so we
> > all know what we are talking about. I had my facts wrong too and nobody
> > corrected me, when I uttered them here in this thread. So here's a quick
> > (probably incomplete) round up of what package-lock.json does and does not
> > do:
> >
> > - It does provide a snapshot of the dependency tree that can be
> > 

Re: Cordova 8.1.0 (minor release) proposal

[Jan Piotrowski]

#2 sounds absolutely fine to me as this dependency is in cordova-cli
which is only used on developer machines, not included in any deployed
packages.

Besides: Cordova has been shipping software with `npm audit` like
issues for ages and I don't think there has been a "totally
unacceptable in all cases" vote result on that.

-J

2018-09-14 21:31 GMT+02:00  :
> 6. Use manually edited npm-shrinkwrap.json to force a more recent version
> of `inquirer` ourselves. Little work, no audit warnings for the users. I
> could do that when the branch is ready. However, we should test the whole
> thing with a alpha suffix or something like that first.
>
> Am Fr., 14. Sep. 2018 um 21:18 Uhr schrieb Chris Brody <
> chris.br...@gmail.com>:
>
>> Unfortunately I spotted a catch-22 situation while working on CLI
>> 8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
>> * insight@0.8 (0.8.4) has the audit issue
>> * newer insight starting with 0.9 uses inquirer@5 which does not
>> support Node.js 4.
>>
>> I can think of the following alternatives:
>>
>> 1. skip the proposed 8.1.0 minor release
>> 2. publish 8.1.0 minor release with known audit issue in the CLI
>> 3. drop use of insight in 8.1.0 minor release
>> 4. ask insight to publish 0.8.5 release that resolves the audit issue
>> 5. publish special fork of insight which resolves the audit issue for
>> 8.1.0 minor release
>>
>> Disadvantages of each alternative:
>>
>> 1: Users do not get some needed updates before the next major release.
>> I think the major ones are:
>> - use of cordova-android@~7.1.x by default
>> - use of cordova-windows@~6.0.x by default
>>
>> 2: Bad practice, with possible responsibility for unknown security
>> issues. While I would not expect any real security issues in practice,
>> I would say better safe than sorry.
>>
>> 3. I think this kind of behavior should not be dropped in minor
>> release, only to come back in next major release.
>>
>> 4. I highly doubt they would be motivated to do such a thing for us.
>> Support for deprecated Node.js 4 is not desired in other projects
>> unless absolutely necessary.
>>
>> 5. One more package for us to manage and maintain, on a temporary basis
>>
>> To be honest I really wouldn't mind if we would just make the new
>> release to drop Node.js 4 support and abandon support for the existing
>> package releases.
>> On Fri, Sep 14, 2018 at 9:25 AM  wrote:
>> >
>> > Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
>> > chris.br...@gmail.com>:
>> >
>> > > Thanks Raphael for the reminder about insight, which I overlooked. I
>> > > personally do not like the idea of an extra reminder message before the
>> > > next major release. I would like to consider this over the weekend
>> > >
>> >
>> > That could be resolved in a few ways:
>> >
>> >- rolling back to previous version (can't remember if it had audit
>> >issues)
>> >- Using insight's `config` option [1] with a config provider that uses
>> >the same file as before. The commit that changed the config store was
>> [2]
>> >
>> > Cheers
>> >
>> > [1]: https://github.com/yeoman/insight#config
>> > [2]:
>> >
>> https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 8.1.0 (minor release) proposal

[raphinesse]

6. Use manually edited npm-shrinkwrap.json to force a more recent version
of `inquirer` ourselves. Little work, no audit warnings for the users. I
could do that when the branch is ready. However, we should test the whole
thing with a alpha suffix or something like that first.

Am Fr., 14. Sep. 2018 um 21:18 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:

> Unfortunately I spotted a catch-22 situation while working on CLI
> 8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
> * insight@0.8 (0.8.4) has the audit issue
> * newer insight starting with 0.9 uses inquirer@5 which does not
> support Node.js 4.
>
> I can think of the following alternatives:
>
> 1. skip the proposed 8.1.0 minor release
> 2. publish 8.1.0 minor release with known audit issue in the CLI
> 3. drop use of insight in 8.1.0 minor release
> 4. ask insight to publish 0.8.5 release that resolves the audit issue
> 5. publish special fork of insight which resolves the audit issue for
> 8.1.0 minor release
>
> Disadvantages of each alternative:
>
> 1: Users do not get some needed updates before the next major release.
> I think the major ones are:
> - use of cordova-android@~7.1.x by default
> - use of cordova-windows@~6.0.x by default
>
> 2: Bad practice, with possible responsibility for unknown security
> issues. While I would not expect any real security issues in practice,
> I would say better safe than sorry.
>
> 3. I think this kind of behavior should not be dropped in minor
> release, only to come back in next major release.
>
> 4. I highly doubt they would be motivated to do such a thing for us.
> Support for deprecated Node.js 4 is not desired in other projects
> unless absolutely necessary.
>
> 5. One more package for us to manage and maintain, on a temporary basis
>
> To be honest I really wouldn't mind if we would just make the new
> release to drop Node.js 4 support and abandon support for the existing
> package releases.
> On Fri, Sep 14, 2018 at 9:25 AM  wrote:
> >
> > Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> >
> > > Thanks Raphael for the reminder about insight, which I overlooked. I
> > > personally do not like the idea of an extra reminder message before the
> > > next major release. I would like to consider this over the weekend
> > >
> >
> > That could be resolved in a few ways:
> >
> >- rolling back to previous version (can't remember if it had audit
> >issues)
> >- Using insight's `config` option [1] with a config provider that uses
> >the same file as before. The commit that changed the config store was
> [2]
> >
> > Cheers
> >
> > [1]: https://github.com/yeoman/insight#config
> > [2]:
> >
> https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Cordova 8.1.0 (minor release) proposal

[Chris Brody]

Unfortunately I spotted a catch-22 situation while working on CLI
8.1.x WIP in https://github.com/apache/cordova-cli/pull/326:
* insight@0.8 (0.8.4) has the audit issue
* newer insight starting with 0.9 uses inquirer@5 which does not
support Node.js 4.

I can think of the following alternatives:

1. skip the proposed 8.1.0 minor release
2. publish 8.1.0 minor release with known audit issue in the CLI
3. drop use of insight in 8.1.0 minor release
4. ask insight to publish 0.8.5 release that resolves the audit issue
5. publish special fork of insight which resolves the audit issue for
8.1.0 minor release

Disadvantages of each alternative:

1: Users do not get some needed updates before the next major release.
I think the major ones are:
- use of cordova-android@~7.1.x by default
- use of cordova-windows@~6.0.x by default

2: Bad practice, with possible responsibility for unknown security
issues. While I would not expect any real security issues in practice,
I would say better safe than sorry.

3. I think this kind of behavior should not be dropped in minor
release, only to come back in next major release.

4. I highly doubt they would be motivated to do such a thing for us.
Support for deprecated Node.js 4 is not desired in other projects
unless absolutely necessary.

5. One more package for us to manage and maintain, on a temporary basis

To be honest I really wouldn't mind if we would just make the new
release to drop Node.js 4 support and abandon support for the existing
package releases.
On Fri, Sep 14, 2018 at 9:25 AM  wrote:
>
> Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
> chris.br...@gmail.com>:
>
> > Thanks Raphael for the reminder about insight, which I overlooked. I
> > personally do not like the idea of an extra reminder message before the
> > next major release. I would like to consider this over the weekend
> >
>
> That could be resolved in a few ways:
>
>- rolling back to previous version (can't remember if it had audit
>issues)
>- Using insight's `config` option [1] with a config provider that uses
>the same file as before. The commit that changed the config store was [2]
>
> Cheers
>
> [1]: https://github.com/yeoman/insight#config
> [2]:
> https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Jan Piotrowski]

http://cordova.betamo.de/cordova-board-reports-issue-and-pr-searches.php
now exists and displays for multiple quarters (past and present) links
to GitHub searches that show:

- Issues created in quarter (displays individually how many of those
still open and how many closed)
- Issues closed in quarter
- PRs created in quarter (displays individually how many of those
still open and how many closed/merged)
- PRs merged in quarter
- PRs closed in quarter
- PRs closed or merged in quarter

Anything missing?
Please check my queries an logic - I might have a knot in my brain now
from the unmerged/closed/merged stuff now.

It might be worth reporting "open issues and open PRs right now", but
I was not able to think how to build this in a search query for any
point of time. Anyone an idea?

-J

2018-09-14 18:56 GMT+02:00 Shazron :
> Let's get this process down right for next quarter, if we don't get it
> in time for this one.
> Yes, the reporting dates are in the README for tge repo for the draft report.
> On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski  wrote:
>>
>> Thanks for pulling me in here julio.
>>
>> http://cordova.betamo.de/cordova-github-issues-search-strings.php
>> creates the search strings for all issues on all repositories (bottom
>> left).
>>
>> Just adding the time frame doesn't work, with `created:>2018-06-01
>> created:<2018-09-01` added at the end, it seems the second `created`
>> is overwriting the first one and returns all issues until 09-01.
>>
>> But you can exclude all before and after the relevant dates with
>> `-created:<2018-06-01 -created:>2018-09-01`:
>> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-contribute+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server+-created%3A%3C2018-06-01+-created%3A%3E2018-09-01+
>> (via https://stackoverflow.com/a/50183610/252627)
>>
>> Is that what we are looking for?
>>
>> We can probably also search for "PRs closed in quarter" using
>> https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-when-an-issue-or-pull-request-was-closed
>>
>>
>> If so, I can quickly add the generation of these search links to
>> cordova.betamo.de as well. Our quarter starts in June, correct?
>>
>> J
>>
>> 2018-09-14 13:17 GMT+02:00 julio cesar sanchez :
>> > Jan had some filters to easily see/list bugs, but not sure if it's possible
>> > to know the number of created/closes issues by quarter.
>> > Will put him in copy just in case he missed the draft and can chime in to
>> 

[iOS] State of Xcode 10 support

[Darryl Pogue]

A few issues have started to come in regarding the state of Cordova
projects on Xcode 10. This is a rough summary of the situation:

Xcode 10 uses a new build system by default (previously available on
an opt-in basis in Xcode 9). The cordova-ios project structure is not
compatible with this new build system and results in failures.
Officially, we do not claim to support Xcode 10.

Currently the best workaround is to opt-out of the new build system.
Users can do this by specifying
`--buildFlag="-UseModernBuildSystem=0"` on the command line, or adding
the following to build.json under the ios key:

"buildFlag": [
  "-UseModernBuildSystem=0"
]


I would like to investigate what is required to get a cordova-ios
project building with the new build system, and (if the changes are
reasonable) try to get a fix into the next major for
cordova-ios@5.0.0. Going to try to get a coworker to help me poke at
this over the next week or so.

Once that's done, we can evaluate the possibility of backporting to a
4.x release, but I consider that low priority given that Xcode 9 will
still be usable for another year and there's a relatively easy
workaround to use the old build system.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Shazron]

Let's get this process down right for next quarter, if we don't get it
in time for this one.
Yes, the reporting dates are in the README for tge repo for the draft report.
On Fri, Sep 14, 2018 at 7:32 PM Jan Piotrowski  wrote:
>
> Thanks for pulling me in here julio.
>
> http://cordova.betamo.de/cordova-github-issues-search-strings.php
> creates the search strings for all issues on all repositories (bottom
> left).
>
> Just adding the time frame doesn't work, with `created:>2018-06-01
> created:<2018-09-01` added at the end, it seems the second `created`
> is overwriting the first one and returns all issues until 09-01.
>
> But you can exclude all before and after the relevant dates with
> `-created:<2018-06-01 -created:>2018-09-01`:
> https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-contribute+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server+-created%3A%3C2018-06-01+-created%3A%3E2018-09-01+
> (via https://stackoverflow.com/a/50183610/252627)
>
> Is that what we are looking for?
>
> We can probably also search for "PRs closed in quarter" using
> https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-when-an-issue-or-pull-request-was-closed
>
>
> If so, I can quickly add the generation of these search links to
> cordova.betamo.de as well. Our quarter starts in June, correct?
>
> J
>
> 2018-09-14 13:17 GMT+02:00 julio cesar sanchez :
> > Jan had some filters to easily see/list bugs, but not sure if it's possible
> > to know the number of created/closes issues by quarter.
> > Will put him in copy just in case he missed the draft and can chime in to
> > provide more information.
> >
> > El vie., 14 sept. 2018 a las 2:34, Shazron () escribió:
> >>
> >> What Julio said -- broad strokes only.
> >> Julio -- if we have those numbers, we could add them. Unless it's an
> >> automatic process, it won't be reliable.
> >> On Thu, Sep 13, 2018 at 7:35 PM julio cesar sanchez
> >>  wrote:
> >> >
> >> > I don't think that information is relevant for the report, as what we
> >> > usually include are releases and information about them, so it's
> >> > something
> >> > we should mention when we release the master changes, not before.
> >> >
> >> > As the report talks about JIRA issues and we moved to github issues,
> >> > should
> >> > we add the number of github issues created/closed?
> >> >
> >> >
> >> >
> >> > El jue., 13 sept. 2018 a las 13:11, Chris Brody
> >> > ()
> >> > escribió:
> >> >
> >> > > There was a lot of work 

Re: Commit package-lock.json in next major Cordova release or not?

[Oliver Salzburg]

The problems that appear when you have linked dependencies is that npm 
will pick them up as being bundled and mark them as such in the 
lockfile. *However* this behavior has changed in the past. At one point 
this affected any direct dependency, at another point it "only" affected 
dependencies of dependencies.


Either way, the result is:

a) a corrupted lockfile, which has dependencies marked as bundled
b) a lockfile that lists incorrect versions, resulting from linking 
temporary development snapshots together


When you use a local npm cache and you neglected to correctly 
parameterize your npm calls, you now have your custom registry URL in 
the lockfile for every package it installed from there. This makes it 
unusable for others.


The issue that ultimately drove us away from this concept was that 
locally cached packages were installed over linked modules, because the 
package manager did not understand that they are linked.
But because they were linked, the cached package contents were placed in 
my local development checkout of that linked module. That obviously 
caused all uncommitted changes to be deleted.


Additionally, if you already have linked modules set up, but the 
lockfile says that a certain dependency is to be replaced, it will just 
break your link or replace your linked code as soon as you `npm install`.


We had so many issues with this, I'm sure I'm only remembering the tip 
of the ice berg. Maybe all of this was fixed somehow, but I doubt it. At 
the time when I reported these issues, there was little interest in 
resolving them.


However, I'm not unfamiliar with the lockfile-driven workflow as many 
OSS projects I contributed to use it. It is not uncommon to completely 
wipe your node_modules and/or package-lock.json to rebuild it, because 
of corruptions in either entity. And that is something that has been 
confirmed to me many times by other developers. As in "That's just how 
it is."


This entire area of issues was not exclusive to npm either. We 
extensively evaluated yarn regarding these aspects and it performed just 
as poorly.


I consider these aspects unacceptable for a development workflow as they 
introduce an unreliability where I can't have one.


If someone came out and told me "Hey, you've been doing it wrong all 
along. These are your mistakes and this is how you resolve them." then 
I'd be very happy to hear that :)


On 2018-09-14 15:13, raphine...@gmail.com wrote:

Thanks for picking this up again Chris. I think now is a better time for
second thoughts than later.

I've had a look at your experiment and the behavior you observed is to be
expected and desirable, as I explained in more detail in a comment [1]
there. As I also mentioned there, deleting and regenerating package-lock.json
is a valid approach _if and when_ you want to do a full dependency update,
as we regularly do.

Also, thanks for posting Oliver's message here for better visibility in
this discussion. What I _do_ find a bit disturbing is the problems he
mentioned regarding linking (as in `npm link`) of different modules which
are all using lock files. He expressed his concern regarding that
particular use-case again in a comment [2] of a PR where we touched that
topic. I think it is important we test this, since the ability to link
modules is vital for our development workflow and I have no experience with
package-lock.json in projects where a lot of linking is necessary.

Finally, I think we might need to re-evaluate our presumed knowledge about
the topic at hand. I encourage all those interested to read [3][4][5] so we
all know what we are talking about. I had my facts wrong too and nobody
corrected me, when I uttered them here in this thread. So here's a quick
(probably incomplete) round up of what package-lock.json does and does not
do:

- It does provide a snapshot of the dependency tree that can be
committed into source control to avoid automatic updates of (transitive)
dependencies break the build _during development and CI_
- It _does not_ ensure that a user installing the published package gets
exactly the dependency versions that are specified in package-lock.json.
That is what npm-shrinkwrap.json [5] is for.
- It does speed up installation of dependencies in conjunction with `npm
ci` by skipping the entire dependency resolution and using the versions
from the lock file.
- It is required to be present for `npm audit` [6], although it could be
generated ad-hoc.
- It is possible to manually tinker with the lock file to fix audit
issues with transitive dependencies that have no update available. This
requires some special care to prevent npm from resetting these manual
changes, but it's a valuable last-resort option. However, this is far more
useful with npm-shrinkwrap.json to create releases without security
issues.

With that cleared up, my stance on committing package-lock.json is as
follows:

- Faster CI 

Re: Cordova 8.1.0 (minor release) proposal

[raphinesse]

Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:

> Thanks Raphael for the reminder about insight, which I overlooked. I
> personally do not like the idea of an extra reminder message before the
> next major release. I would like to consider this over the weekend
>

That could be resolved in a few ways:

   - rolling back to previous version (can't remember if it had audit
   issues)
   - Using insight's `config` option [1] with a config provider that uses
   the same file as before. The commit that changed the config store was [2]

Cheers

[1]: https://github.com/yeoman/insight#config
[2]:
https://github.com/yeoman/insight/commit/dae6dd4b73b9cebe3c1ad877f467b7b1c58c1d4c

Re: Commit package-lock.json in next major Cordova release or not?

[raphinesse]

Thanks for picking this up again Chris. I think now is a better time for
second thoughts than later.

I've had a look at your experiment and the behavior you observed is to be
expected and desirable, as I explained in more detail in a comment [1]
there. As I also mentioned there, deleting and regenerating package-lock.json
is a valid approach _if and when_ you want to do a full dependency update,
as we regularly do.

Also, thanks for posting Oliver's message here for better visibility in
this discussion. What I _do_ find a bit disturbing is the problems he
mentioned regarding linking (as in `npm link`) of different modules which
are all using lock files. He expressed his concern regarding that
particular use-case again in a comment [2] of a PR where we touched that
topic. I think it is important we test this, since the ability to link
modules is vital for our development workflow and I have no experience with
package-lock.json in projects where a lot of linking is necessary.

Finally, I think we might need to re-evaluate our presumed knowledge about
the topic at hand. I encourage all those interested to read [3][4][5] so we
all know what we are talking about. I had my facts wrong too and nobody
corrected me, when I uttered them here in this thread. So here's a quick
(probably incomplete) round up of what package-lock.json does and does not
do:

   - It does provide a snapshot of the dependency tree that can be
   committed into source control to avoid automatic updates of (transitive)
   dependencies break the build _during development and CI_
   - It _does not_ ensure that a user installing the published package gets
   exactly the dependency versions that are specified in package-lock.json.
   That is what npm-shrinkwrap.json [5] is for.
   - It does speed up installation of dependencies in conjunction with `npm
   ci` by skipping the entire dependency resolution and using the versions
   from the lock file.
   - It is required to be present for `npm audit` [6], although it could be
   generated ad-hoc.
   - It is possible to manually tinker with the lock file to fix audit
   issues with transitive dependencies that have no update available. This
   requires some special care to prevent npm from resetting these manual
   changes, but it's a valuable last-resort option. However, this is far more
   useful with npm-shrinkwrap.json to create releases without security
   issues.

With that cleared up, my stance on committing package-lock.json is as
follows:

   - Faster CI installations and faster/easier usage of `npm audit` are
   purely convenience features for me.
   - Consistent developer builds and updates only on-demand are real
   advantages for me. I just recently spent hours finding out why some tests
   of cordova-lib were suddenly failing. It turned out it was caused by an
   update to `jasmine@3.2.0`.
   - If the package-lock.json really should interfere with our ability to
   link repositories for development, then that would be a deal breaker for me.

However, the primary goal that I wanted to achieve was _immutable
releases_. That is, installing e.g. `cordova@9` should _always install the
exact same set of packages_. What we need for that is npm-shrinkwrap.json.
So IMO whether we decide for or against using package-lock.json, we should
lock down the dependencies for releases of our CLIs, platforms and possibly
plugins by generating and committing a npm-shrinkwrap.json to the _release
branch_ before packaging the release.

Cheers,
Raphael

[1]: https://github.com/apache/cordova-cli/pull/325#issuecomment-421336025
[2]:
https://github.com/raphinesse/cordova-common/pull/1#issuecomment-420950433
[3]: https://docs.npmjs.com/files/package-locks
[4]: https://docs.npmjs.com/files/package-lock.json
[5]: https://docs.npmjs.com/files/shrinkwrap.json
[6]: https://docs.npmjs.com/getting-started/running-a-security-audit

Re: Cordova 8.1.0 (minor release) proposal

[Chris Brody]

Thanks Raphael for reviewing the PR 4 hours ago. Sorry I missed it.

On Fri, Sep 14, 2018, 8:19 AM Jan Piotrowski  wrote:

> What PR needs another review? Raphael reviewed the only one you linked
> in this thread 4 hours ago.
>
> 2018-09-14 14:15 GMT+02:00 Chris Brody :
> > Thanks guys for the feedback. I would also appreciate a review of the PR
> on
> > GitHub (from a PMC member).
> >
> > Thanks Raphael for the reminder about insight, which I overlooked. I
> > personally do not like the idea of an extra reminder message before the
> > next major release. I would like to consider this over the weekend.
> >
> > I will work on the minor release next week if I can get the PMC review.
> >
> > On Fri, Sep 14, 2018, 7:49 AM Oliver Salzburg  >
> > wrote:
> >
> >> I feel like this would help move things forward. So I'm in favor.
> >>
> >>
> >> On 2018-09-14 08:24, Chris Brody wrote:
> >> > I would like to propose making 8.1.0 minor release, which would
> consist
> >> of:
> >> > * new cordova-lib@8.1.0 minor release
> >> > * new cordova-cli@8.1.0 minor release
> >> >
> >> > to accomplish the following:
> >> > * resolve npm audit issues that show up in cordova-lib@8.0.0 &
> >> cordova-cli@8.0.0
> >> > * support cordova-android@~7.1.x and cordova-windows@~6.0.x releases
> by
> >> default
> >> > * stable AppVeyor CI & Travis CI builds
> >> >
> >> > I already raised the proposal on cordova-lib in:
> >> > https://github.com/apache/cordova-lib/pull/693
> >> >
> >> > For cordova-cli the major items would be to update insight, to resolve
> >> > npm audit issues, and use new cordova-lib@8.1.0 minor release.
> >> >
> >> > Feedback would be appreciated whether this minor release is wanted,
> >> > patch release is really needed for some reason, or if we should wait
> >> > for the next major release.
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Cordova 8.1.0 (minor release) proposal

[Jan Piotrowski]

What PR needs another review? Raphael reviewed the only one you linked
in this thread 4 hours ago.

2018-09-14 14:15 GMT+02:00 Chris Brody :
> Thanks guys for the feedback. I would also appreciate a review of the PR on
> GitHub (from a PMC member).
>
> Thanks Raphael for the reminder about insight, which I overlooked. I
> personally do not like the idea of an extra reminder message before the
> next major release. I would like to consider this over the weekend.
>
> I will work on the minor release next week if I can get the PMC review.
>
> On Fri, Sep 14, 2018, 7:49 AM Oliver Salzburg 
> wrote:
>
>> I feel like this would help move things forward. So I'm in favor.
>>
>>
>> On 2018-09-14 08:24, Chris Brody wrote:
>> > I would like to propose making 8.1.0 minor release, which would consist
>> of:
>> > * new cordova-lib@8.1.0 minor release
>> > * new cordova-cli@8.1.0 minor release
>> >
>> > to accomplish the following:
>> > * resolve npm audit issues that show up in cordova-lib@8.0.0 &
>> cordova-cli@8.0.0
>> > * support cordova-android@~7.1.x and cordova-windows@~6.0.x releases by
>> default
>> > * stable AppVeyor CI & Travis CI builds
>> >
>> > I already raised the proposal on cordova-lib in:
>> > https://github.com/apache/cordova-lib/pull/693
>> >
>> > For cordova-cli the major items would be to update insight, to resolve
>> > npm audit issues, and use new cordova-lib@8.1.0 minor release.
>> >
>> > Feedback would be appreciated whether this minor release is wanted,
>> > patch release is really needed for some reason, or if we should wait
>> > for the next major release.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 8.1.0 (minor release) proposal

[Chris Brody]

Thanks guys for the feedback. I would also appreciate a review of the PR on
GitHub (from a PMC member).

Thanks Raphael for the reminder about insight, which I overlooked. I
personally do not like the idea of an extra reminder message before the
next major release. I would like to consider this over the weekend.

I will work on the minor release next week if I can get the PMC review.

On Fri, Sep 14, 2018, 7:49 AM Oliver Salzburg 
wrote:

> I feel like this would help move things forward. So I'm in favor.
>
>
> On 2018-09-14 08:24, Chris Brody wrote:
> > I would like to propose making 8.1.0 minor release, which would consist
> of:
> > * new cordova-lib@8.1.0 minor release
> > * new cordova-cli@8.1.0 minor release
> >
> > to accomplish the following:
> > * resolve npm audit issues that show up in cordova-lib@8.0.0 &
> cordova-cli@8.0.0
> > * support cordova-android@~7.1.x and cordova-windows@~6.0.x releases by
> default
> > * stable AppVeyor CI & Travis CI builds
> >
> > I already raised the proposal on cordova-lib in:
> > https://github.com/apache/cordova-lib/pull/693
> >
> > For cordova-cli the major items would be to update insight, to resolve
> > npm audit issues, and use new cordova-lib@8.1.0 minor release.
> >
> > Feedback would be appreciated whether this minor release is wanted,
> > patch release is really needed for some reason, or if we should wait
> > for the next major release.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Update dependencies for nightly builds in master

[Oliver Salzburg]

Yes, that makes sense. What I meant was the opposite: When specifying a 
range, it should not be fulfilled with a suffixed version.


On 2018-09-13 16:20, Chris Brody wrote:

If I would try the following command in master branch of
cordova-common (just an experiment):

 npm install cordova-common@^3.0.0-nightly

I would see the following change in package.json:

"dependencies": {
-"cordova-common": "^2.2.0",
+"cordova-common": "^3.0.0-nightly.2018.9.13.9c6cda3d",

Next experiment (again just an experiment): remove generated
node_modules and package-lock.json artifacts (package-lock.json is not
yet committed in cordova-common and update package.json as follows:

diff --git a/package.json b/package.json
index 9f3bdc23..e488c149 100644
--- a/package.json
+++ b/package.json
@@ -19,3 +19,3 @@
"dependencies": {
-"cordova-common": "^2.2.0",
+"cordova-common": "^3.0.0-nightly",
  "cordova-create": "^1.1.0",

then after npm install I get the following result from grep version
node_modules/cordova-common/package.json:

   "version": "3.0.0-nightly.2018.9.13.9c6cda3d"

One more experiment: if I would try the following change to package.json:

diff --git a/package.json b/package.json
index 9f3bdc23..01c549dc 100644
--- a/package.json
+++ b/package.json
@@ -19,3 +19,3 @@
"dependencies": {
-"cordova-common": "^2.2.0",
+"cordova-common": "^2.2.1-nightly",
  "cordova-create": "^1.1.0",

then do clean npm install (node_modules and package-lock.json
artifacts removed) I get the following result from grep version
node_modules/cordova-common/package.json:

   "version": "2.2.5"

These results indicate to me that depending on "-rc" version with
caret (^) should do what we want: use latest "-rc" version available
until we publish the major release, and then use the major release.

FYI this seems to be documented in
https://github.com/npm/node-semver#prerelease-tags which is linked by
https://semver.npmjs.com/.




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova 8.1.0 (minor release) proposal

[Oliver Salzburg]

I feel like this would help move things forward. So I'm in favor.


On 2018-09-14 08:24, Chris Brody wrote:

I would like to propose making 8.1.0 minor release, which would consist of:
* new cordova-lib@8.1.0 minor release
* new cordova-cli@8.1.0 minor release

to accomplish the following:
* resolve npm audit issues that show up in cordova-lib@8.0.0 & cordova-cli@8.0.0
* support cordova-android@~7.1.x and cordova-windows@~6.0.x releases by default
* stable AppVeyor CI & Travis CI builds

I already raised the proposal on cordova-lib in:
https://github.com/apache/cordova-lib/pull/693

For cordova-cli the major items would be to update insight, to resolve
npm audit issues, and use new cordova-lib@8.1.0 minor release.

Feedback would be appreciated whether this minor release is wanted,
patch release is really needed for some reason, or if we should wait
for the next major release.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[Jan Piotrowski]

Thanks for pulling me in here julio.

http://cordova.betamo.de/cordova-github-issues-search-strings.php
creates the search strings for all issues on all repositories (bottom
left).

Just adding the time frame doesn't work, with `created:>2018-06-01
created:<2018-09-01` added at the end, it seems the second `created`
is overwriting the first one and returns all issues until 09-01.

But you can exclude all before and after the relevant dates with
`-created:<2018-06-01 -created:>2018-09-01`:
https://github.com/issues?utf8=%E2%9C%93=is%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-contribute+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server+-created%3A%3C2018-06-01+-created%3A%3E2018-09-01+
(via https://stackoverflow.com/a/50183610/252627)

Is that what we are looking for?

We can probably also search for "PRs closed in quarter" using
https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-when-an-issue-or-pull-request-was-closed


If so, I can quickly add the generation of these search links to
cordova.betamo.de as well. Our quarter starts in June, correct?

J

2018-09-14 13:17 GMT+02:00 julio cesar sanchez :
> Jan had some filters to easily see/list bugs, but not sure if it's possible
> to know the number of created/closes issues by quarter.
> Will put him in copy just in case he missed the draft and can chime in to
> provide more information.
>
> El vie., 14 sept. 2018 a las 2:34, Shazron () escribió:
>>
>> What Julio said -- broad strokes only.
>> Julio -- if we have those numbers, we could add them. Unless it's an
>> automatic process, it won't be reliable.
>> On Thu, Sep 13, 2018 at 7:35 PM julio cesar sanchez
>>  wrote:
>> >
>> > I don't think that information is relevant for the report, as what we
>> > usually include are releases and information about them, so it's
>> > something
>> > we should mention when we release the master changes, not before.
>> >
>> > As the report talks about JIRA issues and we moved to github issues,
>> > should
>> > we add the number of github issues created/closed?
>> >
>> >
>> >
>> > El jue., 13 sept. 2018 a las 13:11, Chris Brody
>> > ()
>> > escribió:
>> >
>> > > There was a lot of work done on master branch for next major release
>> > > in
>> > > areas such as performance improvements, internal API cleanup,
>> > > migtation
>> > > away from shelljs, major test improvements that seem to be missing.
>> > >
>> > > On Thu, Sep 13, 2018, 12:14 AM Shazron  wrote:
>> > >
>> > > > Please review and comment
>> > > >
>> 

Re: [BOARD REPORT DRAFT] Sept 2018 Cordova Board Report

[julio cesar sanchez]

Jan had some filters to easily see/list bugs, but not sure if it's possible
to know the number of created/closes issues by quarter.
Will put him in copy just in case he missed the draft and can chime in to
provide more information.

El vie., 14 sept. 2018 a las 2:34, Shazron () escribió:

> What Julio said -- broad strokes only.
> Julio -- if we have those numbers, we could add them. Unless it's an
> automatic process, it won't be reliable.
> On Thu, Sep 13, 2018 at 7:35 PM julio cesar sanchez
>  wrote:
> >
> > I don't think that information is relevant for the report, as what we
> > usually include are releases and information about them, so it's
> something
> > we should mention when we release the master changes, not before.
> >
> > As the report talks about JIRA issues and we moved to github issues,
> should
> > we add the number of github issues created/closed?
> >
> >
> >
> > El jue., 13 sept. 2018 a las 13:11, Chris Brody ( >)
> > escribió:
> >
> > > There was a lot of work done on master branch for next major release in
> > > areas such as performance improvements, internal API cleanup, migtation
> > > away from shelljs, major test improvements that seem to be missing.
> > >
> > > On Thu, Sep 13, 2018, 12:14 AM Shazron  wrote:
> > >
> > > > Please review and comment
> > > >
> > > >
> > >
> https://github.com/apache/cordova-apache-board-reports/blob/master/2018/2018-09.md
> > > >
> > > > I want to get this out before the end of this week. Thanks!
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Cordova 8.1.0 (minor release) proposal

[raphinesse]

The only minor doubt I'd have is about the insight update: as I've
mentioned in the corresponding PR, it will cause _all_ users to be pompted
again about their telemetry preference. I've thought that to be OK for a
major release. Might be a bit strange in a minor though. Just wanted to let
you know.

That being said, I see these releases as nice to have. If someone wants to
do that work, I'm fine with it.

Chris Brody  schrieb am Fr., 14. Sep. 2018, 08:24:

> I would like to propose making 8.1.0 minor release, which would consist of:
> * new cordova-lib@8.1.0 minor release
> * new cordova-cli@8.1.0 minor release
>
> to accomplish the following:
> * resolve npm audit issues that show up in cordova-lib@8.0.0 &
> cordova-cli@8.0.0
> * support cordova-android@~7.1.x and cordova-windows@~6.0.x releases by
> default
> * stable AppVeyor CI & Travis CI builds
>
> I already raised the proposal on cordova-lib in:
> https://github.com/apache/cordova-lib/pull/693
>
> For cordova-cli the major items would be to update insight, to resolve
> npm audit issues, and use new cordova-lib@8.1.0 minor release.
>
> Feedback would be appreciated whether this minor release is wanted,
> patch release is really needed for some reason, or if we should wait
> for the next major release.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Cordova 8.1.0 (minor release) proposal

[Chris Brody]

I would like to propose making 8.1.0 minor release, which would consist of:
* new cordova-lib@8.1.0 minor release
* new cordova-cli@8.1.0 minor release

to accomplish the following:
* resolve npm audit issues that show up in cordova-lib@8.0.0 & cordova-cli@8.0.0
* support cordova-android@~7.1.x and cordova-windows@~6.0.x releases by default
* stable AppVeyor CI & Travis CI builds

I already raised the proposal on cordova-lib in:
https://github.com/apache/cordova-lib/pull/693

For cordova-cli the major items would be to update insight, to resolve
npm audit issues, and use new cordova-lib@8.1.0 minor release.

Feedback would be appreciated whether this minor release is wanted,
patch release is really needed for some reason, or if we should wait
for the next major release.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org