P.S. I would not favor making a major version release before resolving the
CI issue on AppVeyor somehow. It is though the AppVeyor tests that Jan
already discovered some fixes that were needed for VS 2017, if I am not
mistaken. @Jan can you explain this further or am I mistaken somehow?
On Fri,
I wonder if we should also consider CB-12499 to be breaking, considering
that Default.rd.xml triggers the test failure on AppVeyor.
All tests are enabled now right? Or am I mistaken?
On Thu, Feb 8, 2018 at 12:49 PM, Jan Piotrowski
wrote:
> All that change existing
> I wonder if we should also consider CB-12499 to be breaking, considering
> that Default.rd.xml triggers the test failure on AppVeyor.
No. "Breaking" (in context of semver) refers to changing existing
functionality to not work any more or work differently.
CB-12499 just seems "broken" right now.
Do the tests pass on your machines? If so, I think we should move forward with
the 6.0.0 release, and write this off as a CI environment issue.
On Feb 9, 2018, at 7:45 AM, Jan Piotrowski wrote:
>> I wonder if we should also consider CB-12499 to be breaking, considering
The tests pass on my machine if I would change to
10.0.15063.0 (I don't have the old target platform SDK installed with VS
2017 and don't intend to add it there)
On Fri, Feb 9, 2018 at 11:12 AM, Jesse wrote:
> Do the tests pass on your machines? If so, I think we
On Feb 9, 2018 3:15 PM, "Jan Piotrowski" wrote:
Jesse, they do - but I am not sure why. Problem is I don't fully
understand what is going on there... which is why I am hesitant to
just ignore it.
Makes sense to me
Chris, where and how exactly does one install the
Ok, so this version can be compared to the iOS or Android API version?
Then it defintely makes sense to do some work to make this
configurable in a better way in the future.
Jesse, do you want to create the issue? You seem to have a specific
idea already.
To recap:
- We think the test failure is
There is a list of the timeline for all relevant versions here:
https://docs.microsoft.com/en-us/windows/uwp/updates-and-versions/choose-a-uwp-version
There are 2 important values at play:
Target Version : this should probably be the most recent release we
support, probably 16299
Minimum Version
All correct and I agree, except we do need to update TargetPlatformVersion
pr here: https://github.com/apache/cordova-windows/pull/250
Please test this pr on your windows machine and make sure you can create
and run a new cordova-windows project without having to modify the jsproj
file manually.
Created an issue for making this configurable. CB-13862
@purplecabbage
risingj.com
On Fri, Feb 9, 2018 at 4:23 PM, Jesse wrote:
> All correct and I agree, except we do need to update TargetPlatformVersion
> pr here: https://github.com/apache/cordova-windows/pull/250
>
I'm not sure they're what you're looking for but there are three
version-related Windows preferences that seem to be supported in config.xml:
value="10.0.14393.0" />
value="10.0.16299.125" />
Does one or more of these resolve this?
-Terence
On 2/9/2018 6:41 PM,
Nightly build #628 for cordova has succeeded!
The latest nightly has been published and you can try it out with 'npm i -g
cordova@nightly'
For details check build console at
https://builds.apache.org/job/cordova-nightly/628/consoleFull
-
Jenkins for Apache Cordova
Jesse, they do - but I am not sure why. Problem is I don't fully
understand what is going on there... which is why I am hesitant to
just ignore it.
> The tests pass on my machine if I would change to
10.0.15063.0 (I don't have the old target platform SDK installed with VS
2017 and don't intend
13 matches
Mail list logo