You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2018/08/01 05:29:26 UTC
Re: Time to mark major Cordova release & remove committed node_modules?
+1
If the repo does not support node 4 in the master branch, then the version
should be a major bump.
When it gets released, and what else makes it in is a separate discussion
as I see it.
@purplecabbage
risingj.com
On Tue, Jul 31, 2018 at 2:59 PM, Chris Brody <ch...@gmail.com> wrote:
> 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
> <jc...@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 <pi...@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 <ra...@gmail.com>:
> > > > +1
> > > >
> > > > Chris Brody <ch...@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 <dv...@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.brody@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-unsubscribe@cordova.apache.org
> > > >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >> > >
> > > >> >
> > > >> > ------------------------------------------------------------
> ---------
> > > >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >> >
> > > >>
> > > >> ------------------------------------------------------------
> ---------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Time to mark major Cordova release & remove committed node_modules?
Posted by Chris Brody <ch...@gmail.com>.
I expanded the third step in CB-14241 to both remove
bundledDependencies entry from package.json and remove the committed
node_modules directory.
The second step was already tracked in CB-14063, should have added
this info before.
On Wed, Aug 1, 2018 at 2:54 PM Chris Brody <ch...@gmail.com> wrote:
>
> Thanks all for the responses. I would like to restate my plan to be
> sure it is clear to all:
>
> To be done in sequential order on each actively maintained repo:
> * increase the major release number and keep "-dev" at the end
> * drop support for Node.js 4 if it is still present in package.json,
> .travis.yml, appveyor.yml or .appveyor.yml, and wherever else needed
> (I think this was already done in a lot of the more actively
> maintained repos)
> * remove the committed node_modules directory tree if present, which
> would be the case in platforms (cordova-android, cordova-browser,
> cordova-ios, cordova-osx, cordova-windows)
>
> This means that it should be very clear that we are working on the
> next major release, with breaking changes.
>
> I am aware that there are a number of changes in progress in the
> master branch of many repos, no major release is wanted at this time.
>
> Another point is that I may not do this on all repos at once. This
> task could take a while and I am in the middle of making a patch
> release of many packages. In case any other committer wants to do
> these tasks on any of the repos, in the order discussed above, that
> would be fine.
> On Wed, Aug 1, 2018 at 1:29 AM Jesse <pu...@gmail.com> wrote:
> >
> > +1
> >
> > If the repo does not support node 4 in the master branch, then the version
> > should be a major bump.
> > When it gets released, and what else makes it in is a separate discussion
> > as I see it.
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, Jul 31, 2018 at 2:59 PM, Chris Brody <ch...@gmail.com> wrote:
> >
> > > 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
> > > <jc...@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 <pi...@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 <ra...@gmail.com>:
> > > > > > +1
> > > > > >
> > > > > > Chris Brody <ch...@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 <dv...@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.brody@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-unsubscribe@cordova.apache.org
> > > > > >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >> > >
> > > > > >> >
> > > > > >> > ------------------------------------------------------------
> > > ---------
> > > > > >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >> >
> > > > > >>
> > > > > >> ------------------------------------------------------------
> > > ---------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >>
> > > > > >>
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Time to mark major Cordova release & remove committed node_modules?
Posted by Chris Brody <ch...@gmail.com>.
Thanks all for the responses. I would like to restate my plan to be
sure it is clear to all:
To be done in sequential order on each actively maintained repo:
* increase the major release number and keep "-dev" at the end
* drop support for Node.js 4 if it is still present in package.json,
.travis.yml, appveyor.yml or .appveyor.yml, and wherever else needed
(I think this was already done in a lot of the more actively
maintained repos)
* remove the committed node_modules directory tree if present, which
would be the case in platforms (cordova-android, cordova-browser,
cordova-ios, cordova-osx, cordova-windows)
This means that it should be very clear that we are working on the
next major release, with breaking changes.
I am aware that there are a number of changes in progress in the
master branch of many repos, no major release is wanted at this time.
Another point is that I may not do this on all repos at once. This
task could take a while and I am in the middle of making a patch
release of many packages. In case any other committer wants to do
these tasks on any of the repos, in the order discussed above, that
would be fine.
On Wed, Aug 1, 2018 at 1:29 AM Jesse <pu...@gmail.com> wrote:
>
> +1
>
> If the repo does not support node 4 in the master branch, then the version
> should be a major bump.
> When it gets released, and what else makes it in is a separate discussion
> as I see it.
>
>
> @purplecabbage
> risingj.com
>
> On Tue, Jul 31, 2018 at 2:59 PM, Chris Brody <ch...@gmail.com> wrote:
>
> > 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
> > <jc...@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 <pi...@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 <ra...@gmail.com>:
> > > > > +1
> > > > >
> > > > > Chris Brody <ch...@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 <dv...@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.brody@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-unsubscribe@cordova.apache.org
> > > > >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >> > >
> > > > >> >
> > > > >> > ------------------------------------------------------------
> > ---------
> > > > >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >> >
> > > > >>
> > > > >> ------------------------------------------------------------
> > ---------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >>
> > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org