Cordova 9 release plan

[raphinesse]

This issue tracks the releases necessary to finally release Cordova 9. Experimental platforms and plugins as well as cordova-coho and any test tooling have been omitted.

Task List

Ordered release necessary

These release tasks are given in reverse topological order of below dependency graph. That means following it will ensure that every dependency is released before any of its dependents. Items grouped under a top level item can be released concurrently.

• Stage 1
  • cordova-common
• Stage 2
  • cordova-fetch
  • cordova-app-hello-world
  • cordova-node-xcode
  • cordova-js
  • cordova-serve
• Stage 3
  • cordova-create
  • cordova-osx
  • cordova-ios
  • cordova-android
  • cordova-windows
  • cordova-browser
  • cordova-electron
• Stage 4
  • cordova-lib
• Stage 5
  • cordova-cli
  • cordova-plugman
• Stage 6
  • cordova-docs

Plugins

No particular order necessary since they don't depend on anything, nor are they depended on.

• cordova-plugin-battery-status
• cordova-plugin-camera
• cordova-plugin-device
• cordova-plugin-dialogs
• cordova-plugin-file
• cordova-plugin-geolocation
• cordova-plugin-inappbrowser
• cordova-plugin-media
• cordova-plugin-media-capture
• cordova-plugin-network-information
• cordova-plugin-screen-orientation
• cordova-plugin-splashscreen
• cordova-plugin-statusbar
• cordova-plugin-vibration
• cordova-plugin-whitelist
• cordova-plugin-wkwebview-engine

Dependency Graph

Extracted from devDependencies and dependencies defined in package.json.
Additionally, some dependencies have been added manually:

• Every platform depends on cordova-js since they all bundle it
• cordova-lib depends on all stable core platforms, since it has to define which version of them to use

[erisu]

@raphinesse This release plan looks great and very detailed.

The very important question: When are we going to release Cordova 9?

Also adding @dpogue to this question.

Looking at the project board, https://github.com/orgs/apache/projects/2 and the previously agreed item from the dev mailing list, all the items for Cordova 9 release appears to have been completed with a few exceptions (package-lock.json, ...). But now it seems the scope is expanding.

I am hoping we are not increasing the scope and delaying Cordova 9 release for items that may not be important, or can be release in a minor.

Can we list out what are the remaining items and why?

• Android P had already been officially released since August 6, 2018.
• iOS 12 and Xcode 10 is already officially released.

I want to prevent scope creeping if necessary.

[dpogue]

My list of remaining items looks something like this:

• Bridge WebView plugin for UIWebView/WKWebView
• Update Xcode Project to be compatible with Xcode 10
  (WIP at Update project files for Xcode 10 cordova-ios#409, but this needs more testing)
• iOS Cocoapod improvements
  (WIP at CocoaPods Improvement cordova-ios#391, ready to merge?)
• Updating Android gradle files to not use deprecated commands
  (PR at GH-485: (android) Replace deprecated "compile" with "implementation" cordova-android#486, waiting for someone who understands gradle to review)
• Updating Android gradle version to latest to deal with incompatibilities with newest NDK tools
  (See NDK 18 toolchains cordova-android#504, again need someone who understands gradle)

[erisu]

@dpogue

The CocoaPods improvement is done and can be merged in now.

1. Merge cordova-common PR
2. Release cordova-common next major tagged 3.0.0.
3. Update cordova-ios package.json with cordova-common@^3.0.0
4. Merge cordova-ios CocoaPods PR

Is the Android Gradle's latest version actually a requirement for this next major? Without the latest version, does Android P builds fails? This task seems new and unexpectedly added.

I already reviewed Updating Android gradle files to not use deprecated commands and said that the changes were OK. The question I left as a comment only asked if we should allow developers the flexibility to pick between implementation and api. Adding the support is not required for next major.

I knew there were other Gradle PRs that had questions about adding the helper methods into the dependencies scope to better isolate features that not everyone uses for example Kotlin and EnableGoogleServicesPlugin.
apache/cordova-android#438
apache/cordova-android#441

[dpogue]

I think the issue with the Android Gradle latest version is that the current projects are not compatible with the latest Android Studio.

I believe newer versions of gradle are now warning that compile support will be dropped at the end of 2018, and the work to update to implementation is already done, so I think we should get this in the next major. With regards to implementation vs api, I think at the app level implementation makes sense.

[raphinesse]

I stand to what I have said on the mailing list:

I think we just have to start the process. We have to do the releases in order anyway and there is the buy-in phase for each release, so any blockers will surface when it's the turn of the respective repo. The first release that would have to be done is cordova-common.

That being said, I have no capacities to do any release management myself right now.

Things that should be resolved before the respective major release:

• For platforms: Link node_modules during platform creation if it exists #32
• Look for node_modules in any recursive parent directory cordova-fetch#44 (basically finished; would appreciate another review)
• How to handle save: true when requested package is already installed cordova-fetch#47 (would like some opinions before we release the new major)
• Do the deprecation-part of Limit requireCordovaModule to Cordova modules cordova-lib#689

Regarding committing package-lock.json: Since there was little feedback after the latest concerns I would still assume consensus for the original plan. However, we might as well postpone this task to any following release, since the presence of package-lock.json affects development only anyway.

[erisu]

@raphinesse I will try to take a look at those tickets tomorrow that you linked for review and opinions.

• For Link node_modules during platform creation if it exists #32, I also seen this. I looked into it before and it should be a one liner to delete.

• As for the package-lock.json, IMO I would commit it. I don't really experience the negative affects that everyone else seems experience so much. I have actually seen more positive cases. For example: the recent CI tests failure because one of the dependency updated and it had an issue. Locally, it passed because I had the lock. Anyways its just my opinion.

[raphinesse]

@erisu Yes, #32 should be straightfwd. Just needs to be done, and I'm already distracting myself too much 😅.

Re package-lock: I don't care either way for the coming release. Downside is, it's another thing to be done.

I forgot about apache/cordova-common#50 in my previous post. Would be nice to have this in the coming release. I think it's good to go as is, but its verification has been stalled by our uncovering of various Windows issues. Since cordova-common will be the first release to do, our schedule might be too tight to squeeze in this change.

[erisu]

I can start #32 tomorrow as well and put in the PRs for review etc. So you don't distract too much :)

[dpogue]

cordova-common@3.0.0 has been published, which checks off step 1 from the list.

[brody2consult]

I just raised apache/cordova-lib#721 with a proposal for cordova-lib to export the Cordova common object, so that Cordova CLI should not need cordova-common in its dependencies. This proposal should reduce the chance of violating the cordova-common singleton rule. I hope we can get this kind of enhancement into Cordova 9.