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
<oliver.salzb...@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 <oliver.salzb...@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-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
