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.

[brodycj]

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.

[brodycj]

I think it would be ideal if we can squeeze in a couple more updates to cordova-common before Stage 2, in order to use real singletons instead of following the cordova-common singleton rule:

• Refactor CordovaLogger to a singleton class - approved PR in Refactor CordovaLogger to singleton class cordova-common#53
• Refactor CordovaEvents to a singleton class as discussed in Refactor CordovaLogger to singleton class cordova-common#53 (comment)

[erisu]

@brodybits Since cordova-common@3, for Cordova 9, had already been released, I don't think we need to focus on this. The discussion thread 1 and thread 2 is focused on

• cordova-js
• cordova-fetch
• cordova-serve
• cordova-app-hello-world

I am trying to move forward on the Cordova 9 release and stop delaying or scope creeping way too much. For example, this was never a part of the original roadmap or even a hint as future work.

Additionally, as @dpogue commented

I don't think this actually requires anything more than a patch release

Since we are pining cordova-common@^3.0.0 and we do not commit package-lock.json or npm-shrinkwrap.json (for most packages) this means the the patch released would take affect immediately without releasing new tools.

[erisu]

Stage 2 Progress Report:

The following tools and template has been published and its corresponding release blog post has also been posted.

• cordova-app-hello-world@4.0.0
• cordova-fetch@2.0.0
• cordova-js@5.0.0
• cordova-serve@3.0.0

I am planning to begin with stage 3 after winter vacation.

[erisu]

@brodybits Have you finished preparing the cordova-node-xcode@2.0.0 release? I did not do this package since you started the discussion thread for its release back in Dec 10th.

I should be able to start stage 3 release after the Christmas and New Year vacation and will skip iOS and macOS platform release until xcode is completed.

[brodycj]

The following tools and template has been published [...]

Thanks!

Have you finished preparing the cordova-node-xcode@2.0.0 release?

I am still working on it, see apache/cordova-node-xcode#20. If you need it sooner please feel free to publish it yourself and I can continue my work afterwards.

I have also made cordova-common@3.1.0 which uses real singletons, waiting for a couple reviews before publishing.

[brodycj]

FYI the cordova-common singleton rule no longer applies since I published cordova-common@3.1.0, which should be included by the Cordova 9 packages. I just raised apache/cordova-coho#224 to note this in the tools release process.

@erisu I hope to publish xcode@2.0.0 in the next 1-2 weeks; please feel free to publish it now if you need it more quickly.

[erisu]

@brodybits I am planning to begin in the next 2-4 days the self-preparation for discussion & vote of the platform releases.

As it stands, I am only targeting platforms that do not require node-xcode.

If node-xcode is released before, then I will include iOS and macOS to my list.

please feel free to publish it now if you need it more quickly.

If I prepare and publish node-xcode myself, then I will shift my platform release timing to include iOS and macOS with the other platforms.

But, if I release node-xcode, are there outstanding tasks?

I see you had created a Major Update Proposal ticket with an open WIP that is related to the ticket.

If the tasks in this ticket are required, I will wait for your release and continue with the other platforms. If these tasks are not required and what is already merged into master is acceptable, I can take over the release for node-xcode.

[erisu]

If I prepare and publish node-xcode myself, then I will shift my platform release timing to include iOS and macOS with the other platforms.

I also want to point out that there is still an investigation going on another possible iOS and Xcode 10 new build system issue. This may delay the iOS release as well even if I were to release node-xcode.

[erisu]

Stage 3 Progress Report:

The following tools has been published and its corresponding release blog post has also been posted.

• cordova-create@2.0.0

[erisu]

Stage 3 is now Completed.

I will begin preparing the cordova-lib release for stage 4.

As a side note: I will do another Electron patch release. Some how, the last patch release only bumped the versions. When testing, changes from master existed but some how never pushed to the release branch, tag, or npm package.

[erisu]

Stage 4 is now Completed.

I will begin preparing stage 5 (cordova-cli and cordova-plugman) and 6 (cordova-docs).

[erisu]

Stage 5 is now Completed.

cordova@.9.0.0 and plugman@.3.0.0 is now released.

Cordova 9.0.0 docs will soon be set as latest.

[erisu]

Stage 6 is now Completed.

Cordova 9.x docs has been uploaded and now available as the latest docs.

https://cordova.apache.org/docs/en/latest/

[purplecabbage]

This issue is way too exhaustive, and the issue # is reusing an already used issue ( GH-10 )
So I was super confused for a while.

• => GH-10 Incremented package version to -dev
• points to => CB-6699 include files from www folder via single element (use ** glob pattern) cordova-lib#10

I recommend we close this issue and define more granular tasks instead of 1 issue that we keep open for 6 months.

I am grateful of all the work that went into getting all of this out, and a special callout to @erisu for knocking it off.

Let's aim for shorter more incremental work as we release updates to all the plugins. I will try to jump in more @erisu and probably get some advice from you along the way.

[brodycj]

I recommend we close this issue
[...]

Agreed on my part

[janpio]

@purplecabbage On Github issues are not globally unique.

[raphinesse]

I think this issue did serve its purpose quite well and I agree that it can be closed now that Cordova 9 is released.