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-comm
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.9c6
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 vers
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 usin
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 re
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 this
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
> 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 fr
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 accepted,
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 2018-
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, Ja
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.
If
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.salzb...@g
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
dependen
>
> 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,
> r
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 targ
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 wou
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
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 al
24 matches
Mail list logo
