Thank you, Brody, for your investigation into the build configuration and quick fixes to get the repo releasable.
For the follow-up items. * Documentation is not a blocker for the cordova-android repo release as the docs are in cordova-docs. It is though recommended to be updated so we can quickly cut the doc release when we reach that stage. * Deprecate android-targetSdkVersion, android-maxSdkVersion, and other related items in config.xml. The last PR we just merged in uses android-targetSdkVersion from config.xml to set the cdvTargetSdkVersion. I think, for now, we should not add any messages. Let's open a new discussion thread and/or apache/cordova issue to track this discussion. There are many ideas on improving the build configuration (gradle) that even leads down to the Cordova side for passing variables. Some have already even start to cleanup this area locally. So I think we should discuss this but outside of this release. I think we can continue with the release. In fact, I am ready to push the VOTE. :) From: Brody Chris <chris.br...@gmail.com> Reply: dev@cordova.apache.org <dev@cordova.apache.org> Date: February 13, 2019 at 10:39:00 To: dev@cordova.apache.org <dev@cordova.apache.org> Subject: Re: [DISCUSS] Cordova-Android Release A couple followup items: * I suspect we should update the documentation as well * I think it would be good if we could deprecate android-targetSdkVersion, android-maxSdkVersion, and maybe some related items in config.xml, as I had loosely implied on GitHub. I wonder if we want to add the deprecation message before cutting the major release. I think there is no need to hold up cordova-android release for AndroidX testing, as I said earlier, would love confirmation from Julio. Thanks Bryan for your efforts! On Tue, Feb 12, 2019 at 6:57 PM Chris Brody <chris.br...@gmail.com> wrote: > > I will revert the breaking change from PR #664 and finish PR #665 then. > > On Tue, Feb 12, 2019 at 6:50 PM Bryan Ellis <er...@apache.org> wrote: > > > > I also agree. > > > > Since it seems everyone has limited time, I recommend that we revert the > > breaking change and merge in the PR that has the limited scope change and > > resolves the main issues that most people face. > > > > Just test to make sure that the other WIP change is OK. > > > > After release, we can return at any time and clean up the build > > configurations. > > > > I know there is a lot to do, but we can do another major release. I believe > > there are no rules preventing us from releasing a major shortly after > > another. > > > > This major already introduces a lot of awaited features such as Android P > > support, Adaptive Icons, and much more. > > > > > > > > From: Brody Chris <chris.br...@gmail.com> > > Reply: dev@cordova.apache.org <dev@cordova.apache.org> > > Date: February 13, 2019 at 8:13:23 > > To: dev@cordova.apache.org <dev@cordova.apache.org> > > Subject: Re: [DISCUSS] Cordova-Android Release > > > > I would definitely agree that we should do it right and get rid of > > project.properties, along with the other Eclipse artifacts. I already > > raised issues on GitHub to get rid of project.properties and other > > artifacts from Eclipse. > > > > I think none of us have the extra time to go through the needed > > cleanup, that is why I would favor the compromise solution that I > > proposed. (Quick solution would be to revert a recent change, which > > would both be ugly and reintroduce a known issue.) > > > > I think the root cause of our troubles with Android SDK versions has > > been the complexity of the build scripts, I just raised > > https://github.com/apache/cordova-android/issues/667 to clean it up. > > > > I hope we can find a good way to unblock and finish the long awaited > > major release. > > > > On Tue, Feb 12, 2019 at 5:50 PM Darryl Pogue <dvpdin...@gmail.com> wrote: > > > > > > On Tue, Feb 12, 2019 at 2:47 PM Chris Brody <chris.br...@gmail.com> > > > wrote: > > > > [...] > > > > The easy solution to bug 666 would be to revert PR 664, which would > > > > consequently reintroduce cordova-android bug 629. I would favor > > > > resolving it by reading the default targetSdkVersion value from > > > > project.properties, as briefly discussed on GitHub. > > > > > > Ideally we'd set it in settings.gradle and get rid of > > > project.properties entirely :\ > > > > > > Unfortunately, I don't have capacity to pick anything up at the moment. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org