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