You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Chris Brody <ch...@gmail.com> on 2018/09/12 19:29:37 UTC

[DISCUSS] Update dependencies for nightly builds in master

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 all other Cordova tools and platform packages.

I think this would give us better integrity of nightly builds.

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


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

Posted by Darryl Pogue <dv...@gmail.com>.
On Wed, Sep 12, 2018 at 12:29 PM Chris Brody <ch...@gmail.com> 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 accepted, I think we should apply a similar change to the master
> branch of all other Cordova tools and platform packages.
>
> I think this would give us better integrity of nightly builds.

We should not need to make any changes to the master branch for
nightlies to point at other nightlies.
As part of the nightly build process, all the other cordova
dependencies of each module are updated to point to the equivalent
nightly versions. So cordova-cli@nightly-x.y.z is using
cordova-create@nightly-x.y.z and cordova-lib@nightly-x.y.z and
cordova-common@nightly.x.y.z. They reference those explicitly, not
using the "nightly" tag.

We should definitely NOT be pointing anything on the master branch to
specific nightly builds. It should point to whatever version (even
unreleased) we depend on, with a ^ caret so npm will grab the latest.

Reminder that nightly builds are for Cordova developer testing, not
for use by end users because they are not approved releases per Apache
policy.

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


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

Posted by Chris Brody <ch...@gmail.com>.
>
> 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
be mistaken here.

I would be happy to experiment and test this sometime later today or
tonight.

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

Posted by ra...@gmail.com.
Am Mi., 12. Sep. 2018 um 22:01 Uhr schrieb Chris Brody <
chris.brody@gmail.com>:

> On Wed, Sep 12, 2018 at 3:48 PM <ra...@gmail.com> wrote:
> >
> > Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski <
> > piotrowski@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.
>
> I would disagree. I thought that work in master branch *should*
> already be considered to be a non-stable "dev" version. If a change in
> a lower-level dependency would causes another Cordova package to stop
> working, I would rather we discover and resolve this asap.
>

Well then we agree to disagree ;) IMHO, CI tests should run against a
known-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 version update would be picked up
automatically. That's the idea behind committing it in the first place.


> > > How do other libraries handle this inter-connectedness between
> libraries?
> >
> > You could have a look at Babel. They have a lot of packages (managed by
> > lerna AFAIK)
>
> Does that mean we should consider migrating to some kind of a monorepo?
>

No, I was not suggesting anything. Just mentioning that they used it.

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

Posted by Chris Brody <ch...@gmail.com>.
On Wed, Sep 12, 2018 at 3:48 PM <ra...@gmail.com> wrote:
>
> Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski <
> piotrowski@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.

I would disagree. I thought that work in master branch *should*
already be considered to be a non-stable "dev" version. If a change in
a lower-level dependency would causes another Cordova package to stop
working, 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 nightly build name seems to not always
use 2-digit month number. I would propose the following alternative
workaround solutions:

* manually remove everything after the year in the nightly build version number
* we fix the nightly build server to always use 2-digit month and hold
off until October or November 2018

> > How would this change the release process? Another commit to change
> > and pin the dependency?
> >
> I think this shouldn't change anything regarding the release process. It
> just changes the version we are switching away from during release.

Right. We would probably just want to drop the "-nightly*" from the
dependency version number for clarity.

> > How do other libraries handle this inter-connectedness between libraries?
>
> You could have a look at Babel. They have a lot of packages (managed by
> lerna AFAIK)

Does that mean we should consider migrating to some kind of a monorepo?

If so, I would rather to discuss this idea in its own thread.

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


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

Posted by ra...@gmail.com.
Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski <
piotrowski@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 would this change the release process? Another commit to change
> and pin the dependency?
>
I think this shouldn't change anything regarding the release process. It
just changes the version we are switching away from during release.


> How do other libraries handle this inter-connectedness between libraries?

You could have a look at Babel. They have a lot of packages (managed by
lerna AFAIK)

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

Posted by Jan Piotrowski <pi...@gmail.com>.
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 between libraries?

-J

2018-09-12 21:29 GMT+02:00 Chris Brody <ch...@gmail.com>:
> 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 all other Cordova tools and platform packages.
>
> I think this would give us better integrity of nightly builds.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

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


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

Posted by Oliver Salzburg <ol...@gmail.com>.
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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


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

Posted by Chris Brody <ch...@gmail.com>.
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/.

On Thu, Sep 13, 2018 at 9:48 AM Oliver Salzburg
<ol...@gmail.com> wrote:
>
> 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 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 using caret (^) in dependencies means that we should be able to
> > do this just once per Cordova package in a major release.
> >
> > On Thu, Sep 13, 2018, 6:08 AM Oliver Salzburg <ol...@gmail.com>
> > wrote:
> >
> >> 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 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 of
> >>> cordova-fetch and cordova-common, which have necessary updates in
> >>> master but that have not been released to npm yet. Setting the
> >>> dependencies to nightly releases theoretically makes this possible.
> >>>
> >>> An alternative solution of course is to create releases for
> >>> cordova-fetch and cordova-common first, then update cordova-create to
> >>> use those.
> >>>
> >>> Stumbling block here is that Cordova package releases seem to be a big
> >>> deal, historically, and quite some process to follow.
> >>> If we find a way to make cutting a release of a library a quick and
> >>> simple thing, this should be much less of an issue. Correct?
> >>>
> >>> -J
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

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


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

Posted by Oliver Salzburg <ol...@gmail.com>.
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 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 using caret (^) in dependencies means that we should be able to
> do this just once per Cordova package in a major release.
>
> On Thu, Sep 13, 2018, 6:08 AM Oliver Salzburg <ol...@gmail.com>
> wrote:
>
>> 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 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 of
>>> cordova-fetch and cordova-common, which have necessary updates in
>>> master but that have not been released to npm yet. Setting the
>>> dependencies to nightly releases theoretically makes this possible.
>>>
>>> An alternative solution of course is to create releases for
>>> cordova-fetch and cordova-common first, then update cordova-create to
>>> use those.
>>>
>>> Stumbling block here is that Cordova package releases seem to be a big
>>> deal, historically, and quite some process to follow.
>>> If we find a way to make cutting a release of a library a quick and
>>> simple thing, this should be much less of an issue. Correct?
>>>
>>> -J
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>


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


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

Posted by Chris Brody <ch...@gmail.com>.
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 using caret (^) in dependencies means that we should be able to
do this just once per Cordova package in a major release.

On Thu, Sep 13, 2018, 6:08 AM Oliver Salzburg <ol...@gmail.com>
wrote:

> 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 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 of
> > cordova-fetch and cordova-common, which have necessary updates in
> > master but that have not been released to npm yet. Setting the
> > dependencies to nightly releases theoretically makes this possible.
> >
> > An alternative solution of course is to create releases for
> > cordova-fetch and cordova-common first, then update cordova-create to
> > use those.
> >
> > Stumbling block here is that Cordova package releases seem to be a big
> > deal, historically, and quite some process to follow.
> > If we find a way to make cutting a release of a library a quick and
> > simple thing, this should be much less of an issue. Correct?
> >
> > -J
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

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

Posted by Oliver Salzburg <ol...@gmail.com>.
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 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 of
> cordova-fetch and cordova-common, which have necessary updates in
> master but that have not been released to npm yet. Setting the
> dependencies to nightly releases theoretically makes this possible.
>
> An alternative solution of course is to create releases for
> cordova-fetch and cordova-common first, then update cordova-create to
> use those.
>
> Stumbling block here is that Cordova package releases seem to be a big
> deal, historically, and quite some process to follow.
> If we find a way to make cutting a release of a library a quick and
> simple thing, this should be much less of an issue. Correct?
>
> -J
>


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


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

Posted by Jan Piotrowski <pi...@gmail.com>.
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 of
cordova-fetch and cordova-common, which have necessary updates in
master but that have not been released to npm yet. Setting the
dependencies to nightly releases theoretically makes this possible.

An alternative solution of course is to create releases for
cordova-fetch and cordova-common first, then update cordova-create to
use those.

Stumbling block here is that Cordova package releases seem to be a big
deal, historically, and quite some process to follow.
If we find a way to make cutting a release of a library a quick and
simple thing, this should be much less of an issue. Correct?

-J



2018-09-13 10:55 GMT+02:00 Oliver Salzburg <ol...@gmail.com>:
> 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 this basic semantic versioning?
>
> If you have a 1.x of your main package, you want to release 2.x and you have
> a dependency of which you want to include a newer version than is covered by
> your current semver range, then update the range in your package.json before
> you release 2.x.
>
> There is also nothing wrong with bumping dependency semver ranges in a
> module in master. Then you can install the new dependency version when you
> pull the latest changes and update your dependencies. This should obviously
> only be done when there was an important change in the dependency that is
> required in master.
>
> This seems very obvious and is covered thoroughly in at least the
> documentation of npm. What am I missing?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>

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


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

Posted by Oliver Salzburg <ol...@gmail.com>.
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 this basic semantic versioning?

If you have a 1.x of your main package, you want to release 2.x and you 
have a dependency of which you want to include a newer version than is 
covered by your current semver range, then update the range in your 
package.json before you release 2.x.

There is also nothing wrong with bumping dependency semver ranges in a 
module in master. Then you can install the new dependency version when 
you pull the latest changes and update your dependencies. This should 
obviously only be done when there was an important change in the 
dependency that is required in master.

This seems very obvious and is covered thoroughly in at least the 
documentation of npm. What am I missing?

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


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

Posted by Chris Brody <ch...@gmail.com>.
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 Wed, Sep 12, 2018 at 5:06 PM <ra...@gmail.com> wrote:
>
> > 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 frequently.
> We don't need to mess with our committed master versions for this.
> Instead we should do nightly integration tests. That means we would be
> modifying every package.json of every module every night.
> __Temporarily, on the build server and NOT in the repository__
>
> Finally, I agree with Oliver Salzburg. Setting up these tests will be some
> work.
> And I would rather not have the additional integration testing at all, than
> to
> regularly depend on nightly versions in master.
>
> Am Mi., 12. Sep. 2018 um 22:54 Uhr schrieb Chris Brody <
> chris.brody@gmail.com>:
>
> > On Wed, Sep 12, 2018, 4:35 PM Jesse <pu...@gmail.com> 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 to automatically use the latest nightly build of each
> > Cordova dependency (in master branch).
> >
> > 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.
> >
> > If we wanted more flexibility, maybe the git-master version of each
> > > package.json points at the git-master of each other module ... but I
> > don't
> > > think this helps us.
> > >
> >
> > That would have been a worthwhile solution if we did not have the nightly
> > packages published on npm. Since we do have the nightly packages published
> > on npm then yes that idea is not needed.
> >
> > I think is is best to just expect that things are going to break,
> >
> >
> > Yes
> >
> > and we will have to resolve dependencies when we choose to release.
> > >
> >
> > As I said before: according to my proposal we should be able to drop the
> > "-nightly*" part from dependency versions when making major releases.
> >
> > The one criticism that I would agree with is that I don't see anyone else
> > working quite this way. If this proposal is accepted I think it should be
> > documented thoroughly and carefully.
> >
> > In case this proposal is accepted, I am thinking we may want to rename the
> > default branch to something like "edge", "dev", or "unstable" to better
> > reflect the actual less-stable situation.
> >

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


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

Posted by ra...@gmail.com.
> 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 frequently.
We don't need to mess with our committed master versions for this.
Instead we should do nightly integration tests. That means we would be
modifying every package.json of every module every night.
__Temporarily, on the build server and NOT in the repository__

Finally, I agree with Oliver Salzburg. Setting up these tests will be some
work.
And I would rather not have the additional integration testing at all, than
to
regularly depend on nightly versions in master.

Am Mi., 12. Sep. 2018 um 22:54 Uhr schrieb Chris Brody <
chris.brody@gmail.com>:

> On Wed, Sep 12, 2018, 4:35 PM Jesse <pu...@gmail.com> 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 to automatically use the latest nightly build of each
> Cordova dependency (in master branch).
>
> 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.
>
> If we wanted more flexibility, maybe the git-master version of each
> > package.json points at the git-master of each other module ... but I
> don't
> > think this helps us.
> >
>
> That would have been a worthwhile solution if we did not have the nightly
> packages published on npm. Since we do have the nightly packages published
> on npm then yes that idea is not needed.
>
> I think is is best to just expect that things are going to break,
>
>
> Yes
>
> and we will have to resolve dependencies when we choose to release.
> >
>
> As I said before: according to my proposal we should be able to drop the
> "-nightly*" part from dependency versions when making major releases.
>
> The one criticism that I would agree with is that I don't see anyone else
> working quite this way. If this proposal is accepted I think it should be
> documented thoroughly and carefully.
>
> In case this proposal is accepted, I am thinking we may want to rename the
> default branch to something like "edge", "dev", or "unstable" to better
> reflect the actual less-stable situation.
>

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

Posted by Chris Brody <ch...@gmail.com>.
On Wed, Sep 12, 2018, 4:35 PM Jesse <pu...@gmail.com> 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 to automatically use the latest nightly build of each
Cordova dependency (in master branch).

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.

If we wanted more flexibility, maybe the git-master version of each
> package.json points at the git-master of each other module ... but I don't
> think this helps us.
>

That would have been a worthwhile solution if we did not have the nightly
packages published on npm. Since we do have the nightly packages published
on npm then yes that idea is not needed.

I think is is best to just expect that things are going to break,


Yes

and we will have to resolve dependencies when we choose to release.
>

As I said before: according to my proposal we should be able to drop the
"-nightly*" part from dependency versions when making major releases.

The one criticism that I would agree with is that I don't see anyone else
working quite this way. If this proposal is accepted I think it should be
documented thoroughly and carefully.

In case this proposal is accepted, I am thinking we may want to rename the
default branch to something like "edge", "dev", or "unstable" to better
reflect the actual less-stable situation.

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

Posted by ra...@gmail.com.
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.salzburg@gmail.com>:

> 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 is no way to change
> > cordova-create to do this. Using nightly of cordova-comand and
> > cordova-fetch would enable this. Correct?
>
> Why not just publish the new version? I mean, properly, not a -nightly.
>
> Then the projects could depend on these new versions on work properly in
> master as well.
>
> For the time being, the -nightly release would work fine for the
> purpose, but something like that should be occasional, not regular. I
> believe the latter case would produce more failures than it solves.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

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

Posted by Oliver Salzburg <ol...@gmail.com>.
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 is no way to change
> cordova-create to do this. Using nightly of cordova-comand and
> cordova-fetch would enable this. Correct?

Why not just publish the new version? I mean, properly, not a -nightly.

Then the projects could depend on these new versions on work properly in
master as well.

For the time being, the -nightly release would work fine for the
purpose, but something like that should be occasional, not regular. I
believe the latter case would produce more failures than it solves.

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


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

Posted by Jan Piotrowski <pi...@gmail.com>.
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 way to change
cordova-create to do this. Using nightly of cordova-comand and
cordova-fetch would enable this. Correct?

2018-09-12 22:34 GMT+02:00 Jesse <pu...@gmail.com>:
> 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.
> If we wanted more flexibility, maybe the git-master version of each
> package.json points at the git-master of each other module ... but I don't
> think this helps us.
> I think is is best to just expect that things are going to break, and we
> will have to resolve dependencies when we choose to release.
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Sep 12, 2018 at 1:27 PM Oliver Salzburg <ol...@gmail.com>
> 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 the dependency
>> version during the nightly build, publish the nightly and leave master
>> dependent on the stable dependency?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>

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


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

Posted by Jesse <pu...@gmail.com>.
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.
If we wanted more flexibility, maybe the git-master version of each
package.json points at the git-master of each other module ... but I don't
think this helps us.
I think is is best to just expect that things are going to break, and we
will have to resolve dependencies when we choose to release.



@purplecabbage
risingj.com


On Wed, Sep 12, 2018 at 1:27 PM Oliver Salzburg <ol...@gmail.com>
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 the dependency
> version during the nightly build, publish the nightly and leave master
> dependent on the stable dependency?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

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

Posted by Oliver Salzburg <ol...@gmail.com>.
On 2018-09-12 22:31, raphinesse@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, 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 its dependents.

That's a bit of work to set up, but I would rather just not do it at all
then start committing nightly versions into your dependency tree. This
will lead to you constantly having to rebuild your local dependency tree
on every git pull.

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


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

Posted by ra...@gmail.com.
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 <
oliver.salzburg@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 nightly build, publish the nightly and leave master
> dependent on the stable dependency?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

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

Posted by Oliver Salzburg <ol...@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 nightly build, publish the nightly and leave master
dependent on the stable dependency?

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