We've had nightly builds of the Cordova tooling and platforms for a
few years now. Recently the ASF Infrastructure team was replacing the
Jenkins system that previously ran them, so Bryan Ellis ported the
build scripts over to GitHub actions.
For those who are curious, the workflow lives
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
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":
To my understanding, any suffixed version is never matched by a range.
They have to be targeted explicitly.
This can be easily observed at https://semver.npmjs.com/ by entering no
range or *
On 2018-09-13 12:53, Chris Brody wrote:
I would really favor the idea of publishing -rc suffixed
I would really favor the idea of publishing -rc suffixed versions to
resolve the dilemma discussed here. I would favor starting with something
like -rc.01 which could gracefully handle up to 99 rc versions.
Assuming that -rc suffixed versions should be considered stable enough for
master then
Alright, as long as we're talking about a manual process to resolve this
conflict temporarily, I see it as a valid suggestion.
However, I would still prefer if a -rc.0 suffixed version was published
and then depended upon, for clarity.
On 2018-09-13 11:49, Jan Piotrowski wrote:
Chris didn't
Chris didn't really mention the actual problem he tried to solve with
this PR in his initial email, and half the discussion here was about
something totally different.
My understanding of what he did was that he tried to find a way to
test a new version of corova-create that requires new versions
On 2018-09-13 00:34, Chris Brody wrote:
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.
Reading this makes me think I didn't understand an important part of the
discussion. Isn't
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 rel
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
-12 21:36, Jan Piotrowski wrote:
> How do other libraries handle this inter-connectedness between libraries?
That is what we do. We don't produce nightly builds, we trigger
integration jobs on each build of a dependency. The integration job
checks the latest snapshot of the dependency against it
:27 PM Oliver Salzburg
> wrote:
>
>> 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
.
@purplecabbage
risingj.com
On Wed, Sep 12, 2018 at 1:27 PM Oliver Salzburg
wrote:
> 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 b
lzb...@gmail.com>:
> 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 nigh
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 mas
>
> 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
n-to-work state, so we can reliably see from the CI tests if a __PR__
breaks the tests or not. If we want to test integration between Cordova
components, we should run tests with all the master branches linked
together during our nightly builds.
Plus, with package-lock.json committed no vers
orking, I would rather we discover and resolve this asap.
FYI a command like npm install cordova-fetch@nightly would normally
uses a caret (^). This should match all newer nightly builds and even
continue to match once we publish major release of the dependency.
The one caveat here is that the nigh
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
between libraries?
-J
2018-09-12 21:29 GMT+02:00 Chris Brody :
> 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
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
Thanks Darryl!
On Thu, Jul 19, 2018 at 1:05 PM Darryl Pogue wrote:
>
> Apologies for the Jenkins spam, the builds were failing after npm
> revoked all auth tokens and we needed to reauthenticate.
>
> I've figured that part out, so our nightly builds are back to usually
> failing
Apologies for the Jenkins spam, the builds were failing after npm
revoked all auth tokens and we needed to reauthenticate.
I've figured that part out, so our nightly builds are back to usually
failing for flaky reasons instead of consistently failing for auth
reasons. It's an improvement
;> cordova-ios) to the apachebuilds npm user?
> >>
> >> One of the npm owners want to give that a shot? In particular, it
> >> would be nice to have nightly builds for Android while we're trying to
> >> verify the new Android SDK fixes.
> >>
> >>
o to get these working
>> is to grant publish permissions on cordova-android (and probably
>> cordova-ios) to the apachebuilds npm user?
>>
>> One of the npm owners want to give that a shot? In particular, it
>> would be nice to have nightly builds for Android while
; One of the npm owners want to give that a shot? In particular, it
> would be nice to have nightly builds for Android while we're trying to
> verify the new Android SDK fixes.
>
> ~Darryl
>
> On 15 February 2017 at 01:36, Vladimir Kotikov (Akvelon)
> <v-vlk...@microsoft.c
publish permissions on cordova-android (and probably
cordova-ios) to the apachebuilds npm user?
One of the npm owners want to give that a shot? In particular, it
would be nice to have nightly builds for Android while we're trying to
verify the new Android SDK fixes.
~Darryl
On 15 February 2017
Hey Shazron and Fil
The thing with nightly builds is that they are running (or it’d better to say
they had been running until Dec, 9) on Apache infrastructure. More
specifically, this is a build job that is used to run ‘coho nightly’:
https://builds.apache.org/view/All/job/cordova-nightly
I recall Alex saying he enabled parallel builds on cloudapp within the
last week, sounds like it might be relevant. We'll need our MSFT
friends and cloudapp admins to rescue us in this situation!
On Tue, Feb 14, 2017 at 4:12 PM, Shazron wrote:
> I believe they don't run
I believe they don't run anymore. The last one was on
2016-12-09T03:21:01.541Z
Does anyone know what happened?
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-docs/pull/641
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
GitHub user shazron opened a pull request:
https://github.com/apache/cordova-docs/pull/641
CB-11884 - Edit Nightly Builds page based on Apache Board feedback
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shazron/cordova-docs
]
Sent: Monday, August 29, 2016 11:23 AM
To: dev@cordova.apache.org
Subject: Nightly builds - npm publish issue
See:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-11778=01%7c01%7cv-vlkoti%40microsoft.com%7c7309836d15dd4071566a08d3cfe5c2b1
See: https://issues.apache.org/jira/browse/CB-11778
Long story short -- we need to use node 6.x to publish the npm nightlies.
I know the nightly CI uses coho, is it a matter of just updating coho code
and the CI picks it up, or do we have to do something else?
Github user vladimir-kotikov commented on the issue:
https://github.com/apache/cordova-docs/pull/613
Updated and merged. Thanks, @dblotsky, @stevengill
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-docs/pull/613
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user stevengill commented on the issue:
https://github.com/apache/cordova-docs/pull/613
LGTM. Want me to merge it in? Maybe make the change @dblotsky recommended.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
to it
Join the discussion on http://slack.cordova.io/;>Slack
Sign the http://www.apache.org/licenses/#clas;>Individual Contributor License
Agreement (ICLA) and mailto:secret...@apache.org;>submit
it
+Try out the next version of Cordova usin
Github user vladimir-kotikov commented on the issue:
https://github.com/apache/cordova-docs/pull/613
@stevengill, ping
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user vladimir-kotikov commented on the issue:
https://github.com/apache/cordova-docs/pull/613
@nikhilkh, @stevengill, could you please take a look?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
GitHub user vladimir-kotikov opened a pull request:
https://github.com/apache/cordova-docs/pull/613
CB-11477 Add a page about nightly builds
The PR adds a separate page under `contributing` directory with the
information about nightly builds usage
You can merge this pull request
: [DISCUSS] Nightly builds for Cordova
Is it here instead? https://github.com/cordova/cordova-discuss/pull/47
+1
Just to emphasize from the PR discussion, nightlies are fine, they are not
considered official releases and should have the appropriate disclaimers.
From:
https://na01
e any links on the project website that might encourage
non-developers to download and use nightly builds, snapshots, release
candidates, or any other similar package."
My interpretation is, don't put the nightly links on the main page to
install Cordova, which is the main page that we t
Love it +1
Always wanted to be able to $ npm install -g cordova@canary
- Carlos
@csantanapr
> On May 13, 2016, at 5:14 AM, Vladimir Kotikov (Akvelon)
> <v-vlk...@microsoft.com> wrote:
>
> Hi list
>
> I've created a proposal for releasing nightly builds for Cordova. Ple
Hi list
I've created a proposal for releasing nightly builds for Cordova. Please find
details here: https://github.com/cordova/cordova-discuss/pull/42.
I will appreciate any suggestions and feedback.
-
Best regards, Vladimir
Nightly Builds
so long as we unpublish old ones, I believe the list of versions shouldn't grow
indefinitely.
On Mon, Nov 3, 2014 at 4:42 PM, Marcel Kinard cmarc...@gmail.com wrote:
Nice!
Doing an npm info cordova will yield a nightly-increasing number of
entries in the 'version' key
Nice!
Doing an npm info cordova will yield a nightly-increasing number of entries
in the 'version' key?
These would not be artifacts that we could vote on, correct?
On Oct 30, 2014, at 1:16 AM, Steven Gill stevengil...@gmail.com wrote:
I have been doing some work on releasing nightlys
These are not artifacts we could vote on. I am looking into adding a new
command to coho that would do the same steps as nightly but for RCs that we
could vote on and release.
Update for nightlys: Been merged into master, waiting on jenkins access
from apache so I can setup the chronjob to run it
Tools release automation proposal + issue:
https://issues.apache.org/jira/browse/CB-7930
On Mon, Nov 3, 2014 at 1:50 PM, Steven Gill stevengil...@gmail.com wrote:
These are not artifacts we could vote on. I am looking into adding a new
command to coho that would do the same steps as nightly
Cool! Left some minor comments.
On Thu, Oct 30, 2014 at 1:16 AM, Steven Gill stevengil...@gmail.com wrote:
I have been doing some work on releasing nightlys recently.
Please review PR [1] and comment on the issue [2].
[1] https://github.com/apache/cordova-coho/pull/58
[2]
Thanks Steve, this is a very useful feature to implement.
I like the the dryrun idea execOrPretend
On Thu, Oct 30, 2014 at 10:11 AM, Andrew Grieve agri...@chromium.org
wrote:
Cool! Left some minor comments.
On Thu, Oct 30, 2014 at 1:16 AM, Steven Gill stevengil...@gmail.com
wrote:
I have
Really appreciate the comments and feedback.
execOrPretend was implemented by Andrew in cadence release script for
tagging + pushing. I just moved it out to executil so other functions can
use it.
On Oct 30, 2014 8:19 AM, Carlos Santana csantan...@gmail.com wrote:
Thanks Steve, this is a very
any way I think having nightly builds it's great, next conquer the world
with a nightly mobilespec app ready to run on a device using the nightly
build :-)
On Thu, Oct 30, 2014 at 11:22 AM, Steven Gill stevengil...@gmail.com
wrote:
Really appreciate the comments and feedback.
execOrPretend
I have been doing some work on releasing nightlys recently.
Please review PR [1] and comment on the issue [2].
[1] https://github.com/apache/cordova-coho/pull/58
[2] https://issues.apache.org/jira/browse/CB-7904
58 matches
Mail list logo