Re: [CORE PLUGINS][DISCUSS] Roadmap 2017

[Filip Maj]

I just wanted to provide an update on the general topic of modernizing
the core plugins and tracking specific next steps.

I've been doing my best to work through some of the details and open
questions that came up as part of the Core Plugins Roadmap top-level
issue [1].  In my opinion, this issue is a high priority to execute on
as a) it would make cordova more spec-relevant and inch closer towards
APIs that are showing up natively in the browser and b) would reduce
the total plugin/API surface area the cordova PMC is responsible for.
With over two thousand open or in progress issues in JIRA, I feel like
doing everything we can to make maintenance of cordova sustainable is
not only in the best interest of the cordova PMC but also for the
community.

In particular, here are some steps I've taken:

 - I've gone through and summarized next steps and filed specific
issues for plugins marked as "KEEP". For some of these, we don't need
to do anything [2]. For other plugins marked "KEEP", the work involves
possibly sunsetting certain specific platforms' code (e.g. vibration
[3] or battery status [4]). The "KEEP" plugins, generally speaking,
probably require the least amount of work in the short-term.
 - I have started (but not yet finished!) working through the plugins
marked "SUNSET", for example the file-transfer plugin [5]. As I'm
working through and formalizing next steps, it's looking like this
tends to be quite involved - many sub-steps and lots of little things
to do. However, I think executing on these sooner rather than later
makes cordova more sustainable from a maintenance perspective sooner,
so I'd like to see us put progress into this. I still have to go
through the rest of the "SUNSET" plugins and write up similar next
steps / encapsulate those into JIRA issues.
 - I have not yet started going through the plugins marked
"INTEGRATE". I see that Shaz has filed a subtask here about "INTEGRATE
plugin steps" [6], but I'm not exactly sure what you intended with
that. Shaz, can you clarify?

I've also been tagging all of these Core Plugin Roadmap issues,
whether they are integrate, keep or sunset, with the "plugins-next"
label as described in my recent breakdown of surfacing priority issues
[7].

As always, questions/comments/highfives welcome.

Cheers,
Fil

[1] https://issues.apache.org/jira/browse/CB-12708
[2] https://issues.apache.org/jira/browse/CB-12709
[3] https://issues.apache.org/jira/browse/CB-13045
[4] https://issues.apache.org/jira/browse/CB-13046
[5] https://issues.apache.org/jira/browse/CB-13052
[6] https://issues.apache.org/jira/browse/CB-12903
[7] http://markmail.org/message/nhr7uqvtdbg23fyg

On Thu, Jun 8, 2017 at 5:17 PM, Filip Maj  wrote:
> Great job, awesome to see progress on this. 6 plugins to sunset, 5 to
> integrate! Huge progress.
>
> On Thu, Jun 8, 2017 at 7:09 PM, Shazron  wrote:
>> Deadline has passed for:
>> https://issues.apache.org/jira/browse/CB-12708
>>
>> I believe I captured consensus in the issues as best I could. If there was
>> no consensus, the status quo prevails (KEEP).
>>
>> On Tue, May 30, 2017 at 12:58 PM, Shazron  wrote:
>>
>>> Good point, I can imagine that after June 5 they will possibly bake things
>>> into Safari and improve WKWebView, but that will only apply to iOS 11
>>> onwards and would not affect most decisions since we need to be backwards
>>> compat for quite a while.
>>>
>>> For June 1st, it looks like consensus is there for the majority of the
>>> plugins. I'm comfortable to move the deadline to June 6th. If there are any
>>> earth-shattering announcements from Apple, we can bump it up one more week.
>>>
>>>
>>> On Tue, May 30, 2017 at 2:07 AM, julio cesar sanchez <
>>> jcesarmob...@gmail.com> wrote:
>>>
 With the WWDC being next week, should we wait a few more days before
 making
 the final decision?
 After a sneak peek into iOS 11 announcements maybe we can make a better
 decision

 2017-05-22 18:47 GMT+02:00 Shazron :

 > Deadline of June 1st is in 11 days, so get your comments in.
 >
 > On Wed, Apr 26, 2017 at 1:01 PM, Shazron  wrote:
 >
 > > I'm going to put a deadline of June 1st, 2017 to wrap up discussion of
 > the
 > > Roadmap, we need it to be finalized by then if not it will just be
 left
 > in
 > > the wind like previous proposals.
 > >
 > > This gives us a month, more than enough I think, to nail this down --
 > also
 > > since most of the Adobe team will be away on conferences (like
 PhoneGap
 > Day
 > > EU 2017 http://pgday.phonegap.com/eu2017/ -- see you there if you are
 > > going) so this extra time will help.
 > >
 > >
 > >
 > > On Tue, Apr 25, 2017 at 7:11 PM, Shazron  wrote:
 > >
 > >> The PR for the Plugin Audit is originally here:
 > https://github.com/cordo
 > >> 

Highlighting top issues w/ JIRA boards and labels

[Filip Maj]

Hi everyone,

Over the past little while, I've been trying to wrap my head around
what open issues exist within Cordova, which ones are top priority +
how we can identify the most pressing issues, and how to bubble those
up to the top for PMC members and contributor/committers.

With some of the other Adobians, we've slapped together a few JIRA
boards that we think can help wrangle the 2,054+ unresolved issues in
JIRA [1]. The idea is to use two labels to differentiate between
issues identified as "we need to fix this for the next release" and
"we need to fix this at some point in the future."

One board is called the "Cordova Backlog" [2]. It shows open or in
progress issues for _all_ components / repos within Cordova that are
tagged with the 'backlog' label. I think this board helps to
identify/aggregate triaged issues that committers/PMC members feel are
important enough to address at some point - but not necessarily for
the next release. It also gives a nice high-level overview of Cordova
as a whole since it shows issues across all repos. To make an issue
show up in this board, simply add the 'backlog' label to a JIRA issue.

To complement this, and make working towards the next release for
particular components easier, we've added a set of boards we've called
"Next". These boards are per-component (or roughly, per group of
related components), and show open, in progress and completed issues.
The idea with these boards is to give specific repo maintainers +
contributors a shared todo list as they work towards nailing a
release. We already had a "cordova-next" board in the past which was
mainly used in prep for major version releases of the tooling - this
board has been renamed "tools-next." The specific boards created are:
 - browser-next [3] for the cordova-browser platform
 - docs-next [4] for cordova-docs
 - plugins-next [5] for all cordova plugins
 - android-next [6] for cordova-android
 - tools-next [7] for all cordova tooling (cli, lib, fetch, create, etc.)
 - ios-next [8] for cordova-ios
 - windows-next [9] for cordova-windows

To make an issue show up in one of these, apply the relevant *-next
label to an issue, i.e. android-next, or docs-next, or browser-next.
The "release" link available on these boards could also be used to
help create changelogs.

So, to summarize:
 - hoping this can create visibility and a shared backlog / work list
to help with collaboration between contributors
 - hoping a consistent approach across repos can help increase
transparency and lower confusion as contributors work across repos

Open to any comments or questions! My goal with this is to try to
create a shared workflow for contributors, that is relatively
consistent across components, in order to increase ease of
collaboration - this is not set in stone, but rather a first stab, so
I am open to all ideas to try to make this more accessible for
everyone.

Cheers,
Fil


[1] 
https://issues.apache.org/jira/secure/ConfigureReport.jspa?filterid=12320364=components=12312420=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby=Next
[2] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=195
[3] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=193
[4] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=198
[5] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=194
[6] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=190
[7] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=171
[8] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=192
[9] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=191

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-test-platform pull request #1: Doc requirements for platform api exp...

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-test-platform/pull/1#discussion_r128902594
  
--- Diff: PlatformRequirements.md ---
@@ -0,0 +1,144 @@
+
+# New Platform Checklist
+ 
+## Stand-alone scripts
+ 
+bin/create scripts
+- bin/create _(typically a node script)_
+- bin/create.bat for windows
+- windows .bat file typically just calls bin/create with node
+ 
+bin/update
+- not entirely sure this code is run, or needs to exist with newish 
non-destructive platform updates
+ 
+## Package Expectations
+ 
+- Platforms must have a package.json in their root.
+- Package.json exports a 'main', usually `"main": "src/cordova/Api.js"`
+- This allows other modules to simply require() the path to this 
platform and get access to the Api.
+ 
+## Api (Platform) Expectations
+- The PlatformApi class
+- The PlatformApi class is an abstraction around a particular platform 
that exposes all the actions, properties, and methods for this platform so they 
are accessible programmatically.
+- It can install & uninstall plugins with all source files, web assets 
and js files.
+- It exposes a single 'prepare' method to provide a way for 
cordova-lib to apply a project's setting/www content to the platform.
+- The PlatformApi class should be implemented by each platform that 
wants to use the new API flow. For those platforms, which don't provide their 
own PlatformApi, there will be a polyfill in cordova-lib.
+- Platforms that implement their own PlatformApi instance should 
implement all prototype methods of this class to be fully compatible with 
cordova-lib.
+- The PlatformApi instance should define the following field:
+- platform : This is a String that defines a platform name.
+ 
+- Api.js exports static functions
+- there is currently a requirement that the file be called Api.js 
(todo:change that)
+ 
+ 
+- Api.js exports static function `updatePlatform(destination, options, 
events);`
+- PlatformApi.updatePlatform = function (cordovaProject, options) {};
+- The `updatePlatform` method is equal to the bin/update script. It 
should update an already installed platform. It should accept a CordovaProject 
instance, that defines a project structure and configuration, that should be 
applied to the new platform, and an options object.
+- cordovaProject: This is a CordovaProject instance that defines a 
project structure and configuration, that should be applied to the new 
platform. This argument is optional and if not defined, that platform is used 
as a standalone project and not as part of a Cordova project.
+- options : This is an options object. The most common options are :
+- options.customTemplate : This is a path to custom template, that 
should override the default one from platform.
+- options.link : This is a flag that should indicate that the 
platform's sources will be linked to the installed platform instead of copying.
+ - The `updatePlatform` method must return a promise, which is either 
fulfilled with a PlatformApi instance or rejected with a CordovaError.
+ 
+- Api.js exports static function `createPlatform(destination, cfg, 
options, events);`
+- PlatformApi.createPlatform = function(cordovaProject, options) {};
+- The `createPlatform method` is equal to the bin/create script. It 
should install the platform to a specified directory and create a platform 
project. It should accept a CordovaProject instance, that defines a project 
structure and configuration, that should be applied to the new platform, and an 
options object.
+- cordovaProject : This is a CordovaProject instance that defines a 
project structure and configuration, that should be applied to the new 
platform. This argument is optional and if not defined, that platform is used 
as a standalone project and not as part of a Cordova project.
+- options : This is an options object. The most common options are :
+- options.customTemplate : This is a path to custom template, that 
should override the default one from the platform.
+- options.link : This is a flag that should indicate that the 
platform's sources will be linked to the installed platform instead of copying.
+- The `createPlatform` method must return a promise, which is either 
fulfilled with a PlatformApi instance or rejected with a CordovaError.
+ 
+The way most platforms work is somewhat tricky.  The Api.js could be 
anywhere in the platform repo, ex. /templates/cordova/Api.js .  When a new 
project is created for the platform, the platform copies this file (and 
supporting files ) to destination/cordova/Api.js.  The project expectations 
demand that the Api.js file be available at 

[GitHub] cordova-test-platform pull request #1: Doc requirements for platform api exp...

[filmaj]

Github user filmaj commented on a diff in the pull request:

https://github.com/apache/cordova-test-platform/pull/1#discussion_r128902258
  
--- Diff: PlatformRequirements.md ---
@@ -0,0 +1,144 @@
+
+# New Platform Checklist
+ 
+## Stand-alone scripts
+ 
+bin/create scripts
+- bin/create _(typically a node script)_
+- bin/create.bat for windows
+- windows .bat file typically just calls bin/create with node
+ 
+bin/update
+- not entirely sure this code is run, or needs to exist with newish 
non-destructive platform updates
+ 
+## Package Expectations
+ 
+- Platforms must have a package.json in their root.
+- Package.json exports a 'main', usually `"main": "src/cordova/Api.js"`
+- This allows other modules to simply require() the path to this 
platform and get access to the Api.
+ 
+## Api (Platform) Expectations
+- The PlatformApi class
+- The PlatformApi class is an abstraction around a particular platform 
that exposes all the actions, properties, and methods for this platform so they 
are accessible programmatically.
+- It can install & uninstall plugins with all source files, web assets 
and js files.
+- It exposes a single 'prepare' method to provide a way for 
cordova-lib to apply a project's setting/www content to the platform.
+- The PlatformApi class should be implemented by each platform that 
wants to use the new API flow. For those platforms, which don't provide their 
own PlatformApi, there will be a polyfill in cordova-lib.
+- Platforms that implement their own PlatformApi instance should 
implement all prototype methods of this class to be fully compatible with 
cordova-lib.
+- The PlatformApi instance should define the following field:
+- platform : This is a String that defines a platform name.
+ 
+- Api.js exports static functions
+- there is currently a requirement that the file be called Api.js 
(todo:change that)
+ 
+ 
+- Api.js exports static function `updatePlatform(destination, options, 
events);`
+- PlatformApi.updatePlatform = function (cordovaProject, options) {};
+- The `updatePlatform` method is equal to the bin/update script. It 
should update an already installed platform. It should accept a CordovaProject 
instance, that defines a project structure and configuration, that should be 
applied to the new platform, and an options object.
+- cordovaProject: This is a CordovaProject instance that defines a 
project structure and configuration, that should be applied to the new 
platform. This argument is optional and if not defined, that platform is used 
as a standalone project and not as part of a Cordova project.
+- options : This is an options object. The most common options are :
+- options.customTemplate : This is a path to custom template, that 
should override the default one from platform.
+- options.link : This is a flag that should indicate that the 
platform's sources will be linked to the installed platform instead of copying.
+ - The `updatePlatform` method must return a promise, which is either 
fulfilled with a PlatformApi instance or rejected with a CordovaError.
+ 
+- Api.js exports static function `createPlatform(destination, cfg, 
options, events);`
+- PlatformApi.createPlatform = function(cordovaProject, options) {};
+- The `createPlatform method` is equal to the bin/create script. It 
should install the platform to a specified directory and create a platform 
project. It should accept a CordovaProject instance, that defines a project 
structure and configuration, that should be applied to the new platform, and an 
options object.
+- cordovaProject : This is a CordovaProject instance that defines a 
project structure and configuration, that should be applied to the new 
platform. This argument is optional and if not defined, that platform is used 
as a standalone project and not as part of a Cordova project.
+- options : This is an options object. The most common options are :
+- options.customTemplate : This is a path to custom template, that 
should override the default one from the platform.
--- End diff --

To Jesse's point, I would also add that a default template is standard 
structure for a cordova platform.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Nightly build #435 for cordova has succeeded!

[Apache Jenkins Server]

Nightly build #435 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/435/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org