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:
Nightly build #848 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/848/consoleFull
-
Jenkins for Apache Cordova
I will close this and cordova-create#31 as not wanted. But I think the
issue remains unresolved.
In case of major version bump each Cordova package will continue to
keep dependency on previous patch release of other packages until we
make the new release.
I think this should be documented.
On
> I think, if anything, what is needed is an overall test of all the pieces
> > together, but I don't think this means modifying every package.json of
> > every module every night.
> >
>
> That is exactly what my proposal aims to accomplish.
>
I agree that we should test all the pieces together
On Wed, Sep 12, 2018, 4:35 PM Jesse wrote:
> nightly is just master on any given 'night' right?
>
Yes, that is my understanding.
We don't want to update dependent versions of everything all the time ...
>
Agreed. My proposal would use the caret (^) character in the nightly
dependency versions
On Wed, Sep 12, 2018 at 12:29 PM Chris Brody wrote:
>
> Potentially controversial proposal.
>
> For example: https://github.com/apache/cordova-create/pull/31
>
> The proposal is that Cordova packages in the master branch should
> depend on nightly builds, not on old patch release.
>
> If
I agree that this kind of situation should be addressed by a proper release
of the dependency.
If it's a breaking change, so be it. I don't mind if we have cordova-common
23.5.7 in a year from now.
Am Mi., 12. Sep. 2018 um 22:44 Uhr schrieb Oliver Salzburg <
oliver.salzb...@gmail.com>:
> On
On 2018-09-12 22:40, Jan Piotrowski wrote:
> cordova-create uses cordova-common and cordova-fetch. Right now two
> existing releases are pinned as dependencies. cordova-common and
> cordova-fetch have changes in master, that are necessary for new
> things in cordova-create to work. Right now there
On 2018-09-12 22:31, raphine...@gmail.com wrote:
> Yeah, I mean that's what we do with the nightlies already. I agree that it
> would be great to be notified of integration problems ASAP. But to achieve
> that, we should test the nightlies produced during the nightly build.
On 2018-09-12 21:36,
Another aspect I thought this should solve:
cordova-create uses cordova-common and cordova-fetch. Right now two
existing releases are pinned as dependencies. cordova-common and
cordova-fetch have changes in master, that are necessary for new
things in cordova-create to work. Right now there is no
nightly is just master on any given 'night' right?
We don't want to update dependent versions of everything all the time ...
I think, if anything, what is needed is an overall test of all the pieces
together, but I don't think this means modifying every package.json of
every module every night.
Yeah, I mean that's what we do with the nightlies already. I agree that it
would be great to be notified of integration problems ASAP. But to achieve
that, we should test the nightlies produced during the nightly build.
Am Mi., 12. Sep. 2018 um 22:27 Uhr schrieb Oliver Salzburg <
On 2018-09-12 21:29, Chris Brody wrote:
> I think this would give us better integrity of nightly builds.
I don't think I understand the proposal.
If the goal is to produce nightly builds, why not change the dependency
version during the nightly build, publish the nightly and leave master
>
> Plus, with package-lock.json committed no version update would be picked up
> automatically. That's the idea behind committing it in the first place.
>
Newer versions of npm seemed to respect the caret (^) when making
package-lock.json; caret seemed to show up in package-lock.json. But I may
Am Mi., 12. Sep. 2018 um 22:01 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:
> On Wed, Sep 12, 2018 at 3:48 PM wrote:
> >
> > Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski <
> > piotrow...@gmail.com>:
> >
> > > This uses specific nightlies the developer has to select manually,
>
On Wed, Sep 12, 2018 at 3:48 PM wrote:
>
> Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
> > This uses specific nightlies the developer has to select manually, right?
> >
> I would say it would have to, since nightly alone would be an unstable
> moving
Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:
> This uses specific nightlies the developer has to select manually, right?
>
I would say it would have to, since nightly alone would be an unstable
moving target that would regularly break our CI tests.
> How
Interesting suggestion, had a similar discussion with @Erisu today.
This uses specific nightlies the developer has to select manually, right?
How would this change the release process? Another commit to change
and pin the dependency?
How do other libraries handle this inter-connectedness
Potentially controversial proposal.
For example: https://github.com/apache/cordova-create/pull/31
The proposal is that Cordova packages in the master branch should
depend on nightly builds, not on old patch release.
If accepted, I think we should apply a similar change to the master
branch of
Now tracked in: https://github.com/apache/cordova/issues/4
On Thu, Aug 2, 2018 at 6:14 AM Jan Piotrowski wrote:
> +1 - everything that modernizes the tooling that can be used and
> actually uses its added functionality is a win.
>
> 2018-08-02 7:43 GMT+02:00 Chris Brody :
> > Just raised
Definitely milestone - this is exactly what they are meant to be used
for. No need to abuse either issues or project boards.
If naming of a release is unclear at the time of preparation, we can
just call it "next release" and rename after the release is done.
2018-09-12 13:50 GMT+02:00 :
> To
To follow up on my last message:
To track release-blocking tasks in the different repos, we could use issues
(example for cordova-osx [1]), repo-local boards or even milestones.
Any opinions?
[1]: https://github.com/apache/cordova-osx/issues/58
Am Mi., 12. Sep. 2018 um 12:59 Uhr schrieb :
>
What do you mean by "all packages"? These reports were for cordova-osx only.
However, I agree that the major of cordova-osx (and any other package)
should include a dependency update. That is also a part of our release docs
[1]
[1]:
I would suggest you just keep the JavaScript in a separate source file such
as app.js, like you see in the generated project. One less thing to
configure, one less thing that can go wrong, better practice in case you
need to add more JavaScript in the future.
On Tue, Sep 11, 2018 at 11:57 PM
I have a doubt since I did see report messages that one of the packages
(cordova-osx) has security issues in its dependencies. While I would not
expect this to cause a real security problem I would like to see it fixed
in master branch of all packages before shipping a major release.
On Wed, Sep
Hey Bryan,
thanks for following up on the release planning.
As some of you may have noticed, yesterday (in my time zone) we completed
quite a few chores that needed to be done for the next major release. From
my perspective there's nothing that keeps us from starting to release.
Sure, there's
I'm open to having an extended discussion about that. Although we should
probably do that in the appropriate thread:
https://lists.apache.org/thread.html/7f92561d382f143aaf49e083bbe215dcf95a3f4d8b6e3cbb6089a5f3@%3Cdev.cordova.apache.org%3E
Am Di., 11. Sep. 2018 um 13:14 Uhr schrieb Oliver
27 matches
Mail list logo
