[TIMOB-18683] Parity report: Ignore platform specific APIs from Total API count
| GitHub Issue | n/a |
|---|---|
| Type | Improvement |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2016-02-02T03:17:35.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 4.1.0 |
| Components | Tooling |
| Labels | n/a |
| Reporter | Gary Mathews |
| Assignee | Eric Merriman |
| Created | 2015-03-11T20:25:06.000+0000 |
| Updated | 2017-03-22T22:41:10.000+0000 |
Description
Don't include platform specific APIs in the Total API count and platform percentage.
Attachments
| File | Date | Size |
|---|---|---|
| coverage.xlsx | 2016-01-22T08:11:15.000+0000 | 588706 |
PR : https://github.com/appcelerator/titanium_mobile/pull/6712
[~cng] Are we sure this works as expected with this PR in place? We had an email from a new customer worried that windows phone was showing a 27% coverage at: http://builds.appcelerator.com/mobile/master/mobilesdk-6.0.0.v20160120181659-parity.html I imported the list in Excel, ignored all API namespaced for a specific platform and ended up with 63% as you can see in the attached document.
the % coverage = YES / (Total API) but in your excel, your % calculated was (YES + NO) / (Total API) So i think 27% makes sense. basically, just to clarify, this is saying that windows phone has 27% of the total API that includes methods, properties and events in parity with the entire Titanium API.
Marking as fixed since this PR was merged already in Mar 2015.
[~cng] in the excel I calculate YES + N/A where N/A is when the API is platform-specific thus can never be made available to that platform anyway. That's my actual point; by only counting YES you get a much lower score then what it should be. See TIDOC-2429 as well
[~fokkezb] So following your idea, the total API in the parity report should actually ONLY consist of non platform-specific API (it should not contain non-parity .iOS or .android API etc). Then the parity % coverage will be higher. [~ingo] thoughts?
It should include APIs we *have* implemented for that platform plus APIs what we *can never* implement simply because it's specific to another platform. That gives a more relevant (and indeed higher) % and the remaining APIs (those we *could* implement) is a more helpful list to work on improving parity. The way we calculate now Windows will never be 100% since we'll never be able to implement the Action Bar ;)
Closing ticket as fixed.