cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Barham <>
Subject RE: [DISCUSS] Should pinned platforms allow for patch updates?
Date Fri, 22 May 2015 21:21:39 GMT
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 [] 
Sent: Tuesday, May 12, 2015 4:31 PM
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


-----Original Message-----
From: Shazron []
Sent: Tuesday, May 12, 2015 3:38 PM
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 <> 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 <>
> 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:
For additional commands, e-mail:

 ] ][  X  ܚX P ܙݘK \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[ ܙݘK \X K ܙ B
View raw message