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 > >
