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
