On Wed, Sep 12, 2018 at 3:48 PM <[email protected]> wrote: > > Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski < > [email protected]>: > > > 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.
I would disagree. I thought that work in master branch *should* already be considered to be a non-stable "dev" version. If a change in a lower-level dependency would causes another Cordova package to stop working, I would rather we discover and resolve this asap. FYI a command like npm install cordova-fetch@nightly would normally uses a caret (^). This should match all newer nightly builds and even continue to match once we publish major release of the dependency. The one caveat here is that the nightly build name seems to not always use 2-digit month number. I would propose the following alternative workaround solutions: * manually remove everything after the year in the nightly build version number * we fix the nightly build server to always use 2-digit month and hold off until October or November 2018 > > How would this change the release process? Another commit to change > > and pin the dependency? > > > I think this shouldn't change anything regarding the release process. It > just changes the version we are switching away from during release. Right. We would probably just want to drop the "-nightly*" from the dependency version number for clarity. > > How do other libraries handle this inter-connectedness between libraries? > > You could have a look at Babel. They have a lot of packages (managed by > lerna AFAIK) Does that mean we should consider migrating to some kind of a monorepo? If so, I would rather to discuss this idea in its own thread. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
