Another +1 to do-as-npm-does. Both because of existing developer expectations, and because the trend is to move towards npm-isms and it would be a disservice down the road to change the behaviour. Any fork from what npm does should have a strong reason, and not just a prefer-it-this-way, imho.
-Michal On Tue, Mar 24, 2015 at 5:20 PM, Steven Gill <[email protected]> wrote: > Definitely agree with alignment with npm's save! :D > > On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal <[email protected] > > > wrote: > > > I'm in favor of alignment of 'plugin save' behavior with npm's as we > > expect developers to already familiar with that and in future, we plan to > > move to npm. > > > > I liked Andrew's idea of adding a specific version with allowing minor > > version upgrades to be automatic. > > > > As for shrink wrapping, for npm this means locking down the version > > numbers of all modules and their dependencies: > > https://docs.npmjs.com/cli/shrinkwrap . It does not look our > --shrinkwrap > > option does that. > > > > -Nikhil > > > > -----Original Message----- > > From: So, Byoungro [mailto:[email protected]] > > Sent: Tuesday, March 24, 2015 12:40 PM > > To: [email protected] > > Subject: Re: 'cordova plugin save' should also save plugin versions > > > > +1 for making the shrinkwrap as the default for the <save. > > This makes sure the users will restore the same version they saved > before. > > > > Byoungro So > > SSG / DPD / Mobile Computing and Compilers Intel Corporation > > > > > > > > > > > > > > On 3/24/15, 12:31 PM, "Gorkem Ercan" <[email protected]> wrote: > > > > > > > >I think the problem here is shrinkwrap behaviour is the expected > > >because platforms behave that way. I guess we could just make > > >shrinkwrap default and change the flag to --noshrinkwrap. > > >-- > > >Gorkem > > > > > >On 24 Mar 2015, at 13:58, Andrew Grieve wrote: > > > > > >> On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan > > >> <[email protected]> > > >> wrote: > > >> > > >>> They are related but not same. > > >>> > > >>> CB-8594 asks to save the plugin version information during "cordova > > >>> plugin add --save". Right now we do not save version unless the > > >>> command is "cordova plugin add --save --shrinkwrap". This behaviour > > >>> allows plugins to be restored to the latest possible version > > >>> available if they are not explicitly shrinkwrapped. > > >>> > > >> > > >> How about doing what npm does, and always save the version, but save > > >> it as "^1.0.3", so that you still get updates, but not major version > > >> changes? > > >> > > >> > > >> > > >>> > > >>> As for CB-8733, "cordova plugin save" command can not save the > > >>> version information even if it had wanted to because fetch.json is > > >>> missing that information. It is a bug. > > >>> -- > > >>> Gorkem > > >>> > > >>> On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden > > >>> <[email protected]> > > >>> wrote: > > >>> > > >>>> Is that a dupe of https://issues.apache.org/jira/browse/CB-8594? > > >>>> > > >>>> On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales > > >>>> <[email protected]> > > >>>> wrote: > > >>>>> > > >>>>> > > >>>>> Currently, version info is not saved for plugins in the fetch.json. > > >>> That > > >>>>> needs to be added so that plugin version can be saved in the > > >>> config.xml. > > >>>> It > > >>>>> should follow what 'cordova platform save' does. I created a jira > > >>>>> item > > >>>> for > > >>>>> this: https://issues.apache.org/jira/browse/CB-8733 and opened a > > >>>>> pull > > >>>>> request: https://github.com/apache/cordova-lib/pull/189. If > > >>>>> someone > > >>>> could > > >>>>> review it and provide any feedback. > > >>>>> > > >>>>> Thanks, > > >>>>> Edna Morales > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> > > >>> > > >>>===================================================================== > > >>>=== > > >>>=== > > >>>> Raymond Camden, Developer Advocate for MobileFirst at IBM > > >>>> > > >>>> Email : [email protected] > > >>>> Blog : www.raymondcamden.com > > >>>> Twitter: raymondcamden > > >>>> > > >>>> ------------------------------------------------------------------- > > >>>> -- To unsubscribe, e-mail: [email protected] > > >>>> For additional commands, e-mail: [email protected] > > >>>> > > >>>> > > >>> > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [email protected] > > >For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
