We shall keep a close eye on how this goes. Issue: https://issues.apache.org/jira/browse/CB-9075
It is already impossible to know what version of platforms people are using with what versions of cli as it is very simple to upgrade. Ex. Using CLI 3.5.0, I could go `cordova platform add ios@3.8.0` Only reliable way to get what version people are using is for them to give us the output of `cordova platform ls` and `cordova info` (which we should update to include more installed platform info) when reporting issues. Our CLI has gone through many iterations now where old platforms work with new cli's and old clis work with new platforms. Until we have a matrix of tests with old/new versions, I think sticking to patch releases is the way to go. As long as we are following semver properly, we shouldn't run into problems but lets see how it goes. On Sun, May 24, 2015 at 8:01 AM, Brian LeRoux <b...@brian.io> wrote: > I think we should experiment but I'd like to throw a strong caution to this > line of thinking. > > Most of the issues in dependency hell are due to transient effects. Module > A updates but is unaware of Semver or mistakenly creates a side effect. Now > two people with the same version of Cordova have different experiences. One > potentially bad. If we pin versions the modules will be the same for > everyone everywhere. > > Sometimes the functional crowd calls this idempotence. [1] I call it sanity > as ultimately release version tagging is a tool for issue tracking. If we > have issues that sometimes appear and sometimes do not we will have a > quality problem. > > Lets run the experiment, but if even one issue comes up due to transient > modules I will be bringing this thread back up! > > [1] http://en.wikipedia.org/wiki/Idempotence > > On Fri, May 22, 2015 at 5:24 PM, Steven Gill <stevengil...@gmail.com> > wrote: > > > I'm okay with accepting patch changes without upgrading the tooling for > > now. If it works well and once we have more extensive testing in place, > we > > can swap to accepting minor changes. > > > > -Steve > > > > On Fri, May 22, 2015 at 2:21 PM, Tim Barham <tim.bar...@microsoft.com> > > wrote: > > > > > 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 K K[XZ[ > > > ] ][ X ܚX P ܙ ݘK \ X K ܙ B ܈ Y ] [ۘ[ [X[ K[XZ[ > > > ] Z [ ܙ ݘK \ X K ܙ B > > > > > >
