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

Reply via email to