To clarify a few things: By "mark major Cordova release" I meant "mark major Cordova release dev version", such as cordova-ios@5.0.0-dev, cordova-windows@7.0.0-dev, etc. as I had said in a couple other responses. I also confirmed in a couple other responses that I would not make any actual major release yet. I hope I got this clear now, please respond if not.
My idea was that "minor" patch releases would be made from existing patch release branches, e.g. 4.5.x for iOS, 6.0.x for Windows, etc. etc. It should be straightforward to cherry-pick anything we need from master as needed moving forward. A possible alternative would be to make new minor release branches based off of master now. But I don't see much benefit of new minor release branches at this point. For the upcoming patches I would rather not include any more changes than necessary. And for subsequent "minor" patch releases I think it would be less "busy work" to continue with the existing patch release branches than make new minor release branches. But I would appreciate feedback if anyone would like to discuss a counterpoint here. Yes I am planning to make a new "minor" CLI patch release with latest cordova-android, cordova-windows, and other platforms pinned, once I publish the remaining platform patches and update other needed tools packages. And it should be no problem to make additional CLI patch releases with more platform "minor" patches if needed. (I think you can start to see it takes so much @#$% time to update, test, review, document, and publish every single patch release.) An additional point is that if someone publishes another cordova-android@7.0.x patch with SDK & plugin problems solved within the next few days I would be happy to include it in the coming CLI patch release. I would appreciate a response if this addresses the concerns or not. On Tue, Jul 31, 2018 at 5:27 PM julio cesar sanchez <jcesarmob...@gmail.com> wrote: > > I think the node deprecation is enough for a major bump, but we should take > this opportunity to make any other needed breaking change. > > But as next major releases will take time, not sure if we could do a last > cli (minor) release with latest Cordova-Android and Cordova-windows pinned. > This will benefit services such as phonegap build that don’t allow to > choose the platform version and use the pinned version instead (and people > who doesn’t know they can install newer versions), which is a blocker for > people using push plugin as it requires Cordova-Android 7.1.0. > > > > > El martes, 31 de julio de 2018, Jan Piotrowski <piotrow...@gmail.com> > escribió: > > > So this would e.g. bump cordova-windows master from 6.1.0-dev to > > 7.0.0-dev, so it would be clear that the next release would most > > probably be a major one, correct? > > > > Actual release of that version would only happen if there are enough > > "real" changes that justify a major release anyway, right? > > > > -J > > > > 2018-07-31 22:37 GMT+02:00 <raphine...@gmail.com>: > > > +1 > > > > > > Chris Brody <chris.br...@gmail.com> schrieb am Di., 31. Juli 2018, > > 21:23: > > > > > >> Exactly, thanks for the clarification. > > >> On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue <dvpdin...@gmail.com> > > wrote: > > >> > > > >> > +1 > > >> > > > >> > Just to be clear, we're proposing to bump to the next major -dev > > >> > version, not actually making any major version releases yet, correct? > > >> > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev > > >> > > > >> > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody <chris.br...@gmail.com> > > >> wrote: > > >> > > > > >> > > Now that we have dropped support for deprecated Node.js 4 in master > > >> > > branch of most repos, I think it is high time to do the following: > > >> > > * mark next major release version in the affected repos > > >> > > * remove committed node_modules from the affected platform repos > > >> > > > > >> > > I would like to request feedback within the next 1-2 days in case of > > >> > > any objections. I would like to proceed with these items within the > > >> > > next week in case there are no major objections. > > >> > > > > >> > > ------------------------------------------------------------ > > --------- > > >> > > 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 > > >> > > >> > > > > --------------------------------------------------------------------- > > 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
