Our thought process to use ~ over ^ for pinned platforms was because we don't have a solid testing matrix to make sure we are supporting backwards compatibility. If we are all sticking to semver (which I think we are), we should be able to allow minor updates too. It is just safer to allow only patch updates for now until we have that test matrix.
I see the reasoning to make our --save consistent with how we are handling pinned versions. Until we have the test matrix in place, it is probably for the best. I would like to see us go back to using ^ once we have our test matrix in place. But we need to build up to that point and make sure we don't break backwards compatibility with minor releases. One of the reasons I want us to eventually follow npm's --save model is because the dreamer in me would like us to eventually support package.json in cordova projects one day. On Thu, Jun 11, 2015 at 9:07 AM, Mefire O. <ommen...@microsoft.com> wrote: > +1 for moving towards consistency, following the same strategy as > platforms that we pin down. > > Thanks, > Mefire > > -----Original Message----- > From: Tim Barham [mailto:tim.bar...@microsoft.com] > Sent: Thursday, June 11, 2015 8:23 AM > To: 'dev@cordova.apache.org' > Subject: [DISCUSS] Switch to tilde versions for --save > > When we implemented --save for platforms and plugins, we decided to save > versions as caret ranges to be consistent with current npm behavior. > However, when we made our pinned platforms more flexible we decided to go > with tilde ranges rather than caret ranges to keep things a bit more locked > down. > > I think for consistency we should probably do the same thing with the > --save command. It is very easy for users to get into a situation that > bypasses our preferred pinned platform behavior (which only allows patch > updates, not minor version updates) using the --save command, and the > results can be unexpected. I believe internal consistency is more important > than consistency with npm functionality, and will provide a better > experience for our users. > > Any others have thoughts one way or another? > > Thanks, > > Tim > > > --------------------------------------------------------------------- > 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 > >
