It's been a while since we discussed this, and I'd like to implement the change. I'd like to get some consensus on whether we should go with accepting patch changes only ('~1.2.3') or accepting minor version changes ('^1.2.3'). Should we go with patch changes only for now, and see how things go? I wonder how good we will be at maintaining backward compatibility of minor version changes :).
-----Original Message----- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Tuesday, May 12, 2015 4:31 PM To: dev@cordova.apache.org Subject: RE: [DISCUSS] Should pinned platforms allow for patch updates? > For platform releases, we would have to test it with the oldest version of > the CLI that could potentially pull it down. This one worries me a bit in terms of the testing burden and the version matrix that we will need to support. Totally in favor of having patch versions be available right away without requiring a tools release. Thanks, Nikhil -----Original Message----- From: Shazron [mailto:shaz...@gmail.com] Sent: Tuesday, May 12, 2015 3:38 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Should pinned platforms allow for patch updates? +1 on loosening the grip on platform pinning On Tue, May 12, 2015 at 3:21 PM, Steven Gill <stevengil...@gmail.com> wrote: > I am totally on board with --save flag saving '^1.2.3' in config.xml > since it mimics the behavior of npm --save. No need to change anything. > > The more I think about it, the more I think we should loosen our grips > on platform pinning. As long as we are being semver compliant for all > of our platforms, we shouldn't run into issues. > > I like the idea of changing our pins to `^1.2.3` so it respects major only. > It would grab the newest released version of the platform with the > same major. This would only impact new projects or projects that are > adding a platform for the first time. Existing projects would still > have to cordova platform rm PLATFORM and cordova platform add PLATFORM > to get the latest platform. > > One of the reasons we originally wanted to keep pinning was so we > could easily help users when they tell us what version of Cordova they > are having problems with. With the ability to add whatever version of > platforms via `cordova platform add windows@VERSION`, knowing the cli > version doesn't give us the details we want. Users can get installed > platform versions with `cordova platform ls`. > > If we make this change, we should review our fetch/cache logic to see > if it would grab the latest if an older version exists). > > We seem to have a fairly good track record with newer platform > versions working with older CLI versions. Everytime we do a tools > release, we could update the pinned versions to the latest released > ones/newest version cli was tested with at release time. For platform > releases, we would have to test it with the oldest version of the CLI > that could potentially pull it down. > > What do others think? > > > > > > > On Tue, May 12, 2015 at 6:36 AM, Tim Barham <tim.bar...@microsoft.com> > wrote: > >> ?Currently our pinned platforms are all in the form "1.2.3", which I >> expect means we'll always get that exact version. Should we instead >> use the form "1.2.x" to allow for patches without having to do a tools >> release? >> >> >> BTW... When you add a platform, and we use the pinned version of, >> say, '1.2.3', if you use the '--save' flag, we'll save it to >> config.xml as '^1.2.3', like npm currently doe (in other words... >> 'allow any backwardly compatible version'). This means adding the >> platform later could end up with a later version (even with the minor >> version greater than 2 in this example). Perhaps we need to be >> consistent here - if we change pinned version to use the form >> '1.2.x', then should we save exactly that to config.xml? Or >> alternatively should we use the form '^1.2.3' for our pinned version, >> which will introduce a lot more variation, but will be more consistent with >> how semver and npm work? >> >> >> Thanks! >> >> >> Tim >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ ܙݘK \X K ܙ B