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:[email protected]]
Sent: Tuesday, May 12, 2015 4:31 PM
To: [email protected]
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:[email protected]]
Sent: Tuesday, May 12, 2015 3:38 PM
To: [email protected]
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 <[email protected]> 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 <[email protected]>
> 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: [email protected]
For additional commands, e-mail: [email protected]
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [
X ܚX KK[XZ[
] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ ܙݘK \X K ܙ B
