You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2014/10/02 03:17:39 UTC
[DISCUSS] Deprecate "platform update" command?
There's been a couple bugs come in for Android where our update script has
failed to bring a project in line with what would be created for a new
project: CB-7683, CB-6772
We could put more effort into writing transformations into the update
script, but I think it might be more pragmatic to just tell people to
"platform rm android && platform add android".
Thoughts?
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Josh Soref <js...@blackberry.com>.
Andrew Grieve wrote:
> There's been a couple bugs come in for Android where our update script
>has
> failed to bring a project in line with what would be created for a new
> project: CB-7683, CB-6772
>
> We could put more effort into writing transformations into the update
> script, but I think it might be more pragmatic to just tell people to
> "platform rm android && platform add android".
I don't want to deprecate the command.
But if you want to deprecate the platform script and just have the command
do rm + add, I'm ok with that.
There's no reason that a user should have to write out the pseudo command
that you just wrote.
I think a reasonable implementation would be:
Check for an update script in the new platform, if it exists, use it, if
not, just use rm + add.
Android can then remove its script and get the rm + add behavior.
Re: This list lacks unsubscrbe instructions
Posted by Shazron Abdullah <sh...@gmail.com>.
Not sure how to fix this for you, it’s best to bug the experts at INFRA by filing an issue I suppose.
I haven’t had any problems yet, so far.
> On Oct 14, 2014, at 3:26 PM, Josh Soref <js...@blackberry.com> wrote:
>
> Shazron Abdullah wrote:
>
>>> The lists do not contain footers by default. I’ve requested them:
>>> https://issues.apache.org/jira/browse/INFRA-8425
>
>> The INFRA issue is resolved! Much rejoicing.
>
> I object.
>
> I believe they are poorly configured and are making a total hash of my
> messages.
>
> Take:
> http://mail-archives.apache.org/mod_mbox/cordova-dev/201410.mbox/%3CD062E75
> 2.4DBA4%25jsoref%40blackberry.com%3E
>
>
>
> I sent that message, it looked like this in my sent folder:
> ——
> User-Agent: Microsoft-MacOutlook/14.4.3.140616
> Date: Tue, 14 Oct 2014 14:44:44 -0400
> Subject: Re: Review: Cordova-CLI 4.0.0 Release blog post
> From: Josh Soref <js...@blackberry.com>
> To: "dev@cordova.apache.org" <de...@cordova.apache.org>
> Message-ID: <D0...@blackberry.com>
> Thread-Topic: Review: Cordova-CLI 4.0.0 Release blog post
> References:
> <CA...@mail.gmail.com>
> In-Reply-To:
> <CA...@mail.gmail.com>
> MIME-Version: 1.0
> Content-type: text/plain;
> charset="US-ASCII"
> Content-transfer-encoding: 7bit
>
> Steven Gill wrote:
>
>> Please review and send pull requests!
>>
>> https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordov
>> a-4.md
>
> Working on it...
> ——
>
>
> When I open the same message in Outlook, I see:
> ——
>
> Steven Gill wrote:
>
>> Please review and send pull requests!
>>
>> https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordov
>> a-4.md
>
> Working on it...
>
> ?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�?
> �?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�
> ??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B
> ——
>
>
>
> When I feed
> http://mail-archives.apache.org/mod_mbox/cordova-dev/201410.mbox/raw/%3CD06
> 2E752.4DBA4%25jsoref%40blackberry.com%3E
> To http://www.motobit.com/util/base64-decoder-encoder.asp
> I see:
>
> ——...
>
> ŠëzV¢»¬z¶
> z{L‰Ê貇í1§ºÙh¢OõãõãNµë+Š§jا‚*uÓ®uëM¹Ô*'µéíO*^µìmþ™ZŠw!j» ¶ë_ð*'µéí
> 0ŽºÐ =Û{à 5뎼÷€€a{zâ™Ê&
> ‰íz{S©ì}êÄÊ ŠxjǺà W«²*'×EÕŠ»¬
> œ‘çB…ç$yÖò
> V¦Z'j–œ…ê+MÑ•Ù•¸ ¥±°Ýɽєè4(4(ùA±•…͔ɕ٥•Ü…¹Í•¹ÁÕ±°É•ÅÕ•ÍÑÌ„4(ø
> 4(ù¡ÑÑÁÌè¼½¥Ñ¡Õˆ¹½´½½É‘½Ù„½…Á…¡”µ‰±½œµÁ½ÍÑ̽‰±½ˆ½µ…ÍѕȼÈÀÄдÄÀ´Ä̵½É
> ‘½Ø4(ù„´Ð¹µ4(4)]½É¥¹œ½¸¥Ð¸¸¸4(4(
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
> ——
>
>
>
> When I delete the first character ("F" in "From dev-return"…) from what I
> send to that site, I see:
> ——
>
>> Please review and send pull requests!
>>
>> https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordov
>> a-4.md
>
> Working on it...
>
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•
> È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PÛܙݘK˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[Û
> Û[X[™ ËK[XZ[ˆ]‹Z[ ÛܙݘK˜\XÚK›Ü™
> ——
>
>
>
> This is causing me to doubt my mail client's interoperability and file
> bugs on random pieces of software internally.
>
> I lost a number of hours investigating, as have people on other teams here.
>
> I'm not yet absolutely certain who is to blame, but for the time being,
> I'm going to tentatively imagine that the fault lies with qmail on
> athena.apache.org. The other candidates include
> Microsoft-MacOutlook/14.4.3.140616, XCT102CNC.rim.net … mapi id
> 14.03.0174.001, and ClamAV on apache.org
>
> Note that mail-archives.apache.org is buggy, it's silently truncating the
> message when it encounters the gibberish at the bottom. So, please either
> feed the raw message yourself to your most trusted base64 decoder/mime
> parser, or use your own viewer instead of trusting the rendering it
> provides.
>
>
> ---------------------------------------------------------------------
> 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: This list lacks unsubscrbe instructions
Posted by Josh Soref <js...@blackberry.com>.
Shazron Abdullah wrote:
>>The lists do not contain footers by default. I’ve requested them:
>> https://issues.apache.org/jira/browse/INFRA-8425
>The INFRA issue is resolved! Much rejoicing.
I object.
I believe they are poorly configured and are making a total hash of my
messages.
Take:
http://mail-archives.apache.org/mod_mbox/cordova-dev/201410.mbox/%3CD062E75
2.4DBA4%25jsoref%40blackberry.com%3E
I sent that message, it looked like this in my sent folder:
——
User-Agent: Microsoft-MacOutlook/14.4.3.140616
Date: Tue, 14 Oct 2014 14:44:44 -0400
Subject: Re: Review: Cordova-CLI 4.0.0 Release blog post
From: Josh Soref <js...@blackberry.com>
To: "dev@cordova.apache.org" <de...@cordova.apache.org>
Message-ID: <D0...@blackberry.com>
Thread-Topic: Review: Cordova-CLI 4.0.0 Release blog post
References:
<CA...@mail.gmail.com>
In-Reply-To:
<CA...@mail.gmail.com>
MIME-Version: 1.0
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit
Steven Gill wrote:
>Please review and send pull requests!
>
>https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordov
>a-4.md
Working on it...
——
When I open the same message in Outlook, I see:
——
Steven Gill wrote:
>Please review and send pull requests!
>
>https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordov
>a-4.md
Working on it...
?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�?
�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�
??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B
——
When I feed
http://mail-archives.apache.org/mod_mbox/cordova-dev/201410.mbox/raw/%3CD06
2E752.4DBA4%25jsoref%40blackberry.com%3E
To http://www.motobit.com/util/base64-decoder-encoder.asp
I see:
——...
ŠëzV¢»¬z¶
z{L‰Ê貇í1§ºÙh¢OõãõãNµë+Š§jا‚*uÓ®uëM¹Ô*'µéíO*^µìmþ™ZŠw!j» ¶ë_ð*'µéí
0ŽºÐ =Û{à 5뎼÷€€a{zâ™Ê&
‰íz{S©ì}êÄÊ ŠxjǺà W«²*'×EÕŠ»¬
œ‘çB…ç$yÖò
V¦Z'j–œ…ê+MÑ•Ù•¸ ¥±°Ýɽєè4(4(ùA±•…͔ɕ٥•Ü…¹Í•¹ÁÕ±°É•ÅÕ•ÍÑÌ„4(ø
4(ù¡ÑÑÁÌè¼½¥Ñ¡Õˆ¹½´½½É‘½Ù„½…Á…¡”µ‰±½œµÁ½ÍÑ̽‰±½ˆ½µ…ÍѕȼÈÀÄдÄÀ´Ä̵½É
‘½Ø4(ù„´Ð¹µ4(4)]½É¥¹œ½¸¥Ð¸¸¸4(4(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
——
When I delete the first character ("F" in "From dev-return"…) from what I
send to that site, I see:
——
>Please review and send pull requests!
>
>https://github.com/cordova/apache-blog-posts/blob/master/2014-10-13-cordov
>a-4.md
Working on it...
B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•
È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PÛܙݘK˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[Û
Û[X[™ ËK[XZ[ˆ]‹Z[ ÛܙݘK˜\XÚK›Ü™
——
This is causing me to doubt my mail client's interoperability and file
bugs on random pieces of software internally.
I lost a number of hours investigating, as have people on other teams here.
I'm not yet absolutely certain who is to blame, but for the time being,
I'm going to tentatively imagine that the fault lies with qmail on
athena.apache.org. The other candidates include
Microsoft-MacOutlook/14.4.3.140616, XCT102CNC.rim.net … mapi id
14.03.0174.001, and ClamAV on apache.org
Note that mail-archives.apache.org is buggy, it's silently truncating the
message when it encounters the gibberish at the bottom. So, please either
feed the raw message yourself to your most trusted base64 decoder/mime
parser, or use your own viewer instead of trusting the rendering it
provides.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: This list lacks unsubscrbe instructions
Posted by Shazron Abdullah <sh...@gmail.com>.
The INFRA issue is resolved! Much rejoicing.
> On Oct 2, 2014, at 8:38 AM, Shazron Abdullah <sh...@gmail.com> wrote:
>
> Thanks Matteo,
> The lists do not contain footers by default. I’ve requested them:
> https://issues.apache.org/jira/browse/INFRA-8425
>
>
>> On Oct 2, 2014, at 5:23 AM, Matteo Sisti Sette <ma...@gmail.com> wrote:
>>
>> Usually, at the end of every email received from a mailing list, there is a link to unsubscribe or instructions to do so (such as "send a message to whatever address with whatever subject to unsubscribe from this list").
>>
>> I don't see anything of this in this mailing list and that's disappointing. I had never seen a mailing list lacking this before.
>>
>> I'm sure I'll quickly figure out how to unsubscribe, but I suggest the list managers to fix this.
>>
>>
>> On 02/10/14 03:17, Andrew Grieve wrote:
>>> There's been a couple bugs come in for Android where our update script has
>>> failed to bring a project in line with what would be created for a new
>>> project: CB-7683, CB-6772
>>>
>>> We could put more effort into writing transformations into the update
>>> script, but I think it might be more pragmatic to just tell people to
>>> "platform rm android && platform add android".
>>>
>>> Thoughts?
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: This list lacks unsubscrbe instructions
Posted by Shazron Abdullah <sh...@gmail.com>.
Thanks Matteo,
The lists do not contain footers by default. I’ve requested them:
https://issues.apache.org/jira/browse/INFRA-8425
> On Oct 2, 2014, at 5:23 AM, Matteo Sisti Sette <ma...@gmail.com> wrote:
>
> Usually, at the end of every email received from a mailing list, there is a link to unsubscribe or instructions to do so (such as "send a message to whatever address with whatever subject to unsubscribe from this list").
>
> I don't see anything of this in this mailing list and that's disappointing. I had never seen a mailing list lacking this before.
>
> I'm sure I'll quickly figure out how to unsubscribe, but I suggest the list managers to fix this.
>
>
> On 02/10/14 03:17, Andrew Grieve wrote:
>> There's been a couple bugs come in for Android where our update script has
>> failed to bring a project in line with what would be created for a new
>> project: CB-7683, CB-6772
>>
>> We could put more effort into writing transformations into the update
>> script, but I think it might be more pragmatic to just tell people to
>> "platform rm android && platform add android".
>>
>> Thoughts?
>>
>
Re: This list lacks unsubscrbe instructions
Posted by Ajai Khattri <aj...@bitblit.net>.
On Thu, Oct 02, 2014 at 02:23:21PM +0200, Matteo Sisti Sette wrote:
> Usually, at the end of every email received from a mailing list, there
> is a link to unsubscribe or instructions to do so (such as "send a
> message to whatever address with whatever subject to unsubscribe from
> this list").
>
> I don't see anything of this in this mailing list and that's
> disappointing. I had never seen a mailing list lacking this before.
>
> I'm sure I'll quickly figure out how to unsubscribe, but I suggest the
> list managers to fix this.
Actually most mailing lists these days have headers that tell, and which
most mail clients hide from, you:
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <ma...@cordova.apache.org>
List-Unsubscribe: <ma...@cordova.apache.org>
List-Post: <ma...@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
--
Aj. (who's been using email since 1989)
FaceBook: facebook.com/ajaikhattri
EnoLand: http://flip.it/Gig0n
This list lacks unsubscrbe instructions
Posted by Matteo Sisti Sette <ma...@gmail.com>.
Usually, at the end of every email received from a mailing list, there
is a link to unsubscribe or instructions to do so (such as "send a
message to whatever address with whatever subject to unsubscribe from
this list").
I don't see anything of this in this mailing list and that's
disappointing. I had never seen a mailing list lacking this before.
I'm sure I'll quickly figure out how to unsubscribe, but I suggest the
list managers to fix this.
On 02/10/14 03:17, Andrew Grieve wrote:
> There's been a couple bugs come in for Android where our update script has
> failed to bring a project in line with what would be created for a new
> project: CB-7683, CB-6772
>
> We could put more effort into writing transformations into the update
> script, but I think it might be more pragmatic to just tell people to
> "platform rm android && platform add android".
>
> Thoughts?
>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Michal Mocny <mm...@chromium.org>.
Frederico,
Sounds like this proposal wouldn't conflict with your workflow then. I
think it makes perfect sense to track changes to platforms/ via git for
informational purposes, and yet still consider them build artefacts.
-Michal
On Thu, Oct 2, 2014 at 12:12 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:
> Release build configuration (keystore, provisioning profiles) isn't
> something that plugins can or should do.
> Hooks could do the job indeed, as portrayed in some of http://devgirl.org/
> posts, but I found it easier and safer to keep it under version control.
> That has had another side effect (a good one) that I wouldn't get from
> hooks, which is to know exactly what is generated and inferred by cordova
> as the result artifact application.
>
> Things such as
> android:installLocation, android:windowSoftInputMode,
> android:hardwareAccelerated,
> unrequired feature permissions, android:configChanges, android:launchMode,
> I would have taken much longer to realize what those are, and I'd probably
> realize it with an undesired behaviour at production time.
>
> Unfortunately cordova hasn't filled enough links in configuration from
> config.xml to the artifacts for me to blindly believe it has taken all the
> best decisions for me. It's on the way towards this point, but not there
> yet. That's why I still can't consider the platforms as pure artifacts.
>
> And as I said, Andrew, I'm aware of the destructive nature of such
> procedure, and that's why I still have them under version control: so that
> I can take care of changes closely. A project or team that doesn't change
> anything in platforms manually (or doesn't even know how to do it) will
> probably never have any issues with that.
>
> 2014-10-02 12:36 GMT-03:00 Andrew Grieve <ag...@chromium.org>:
>
> > On Thu, Oct 2, 2014 at 11:21 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Thu, Oct 2, 2014 at 11:07 AM, Frederico Galvão <
> > > frederico.galvao@pontoget.com.br> wrote:
> > >
> > > > I fall in the scenario described by Tommy, but Michael said "it all"
> > > (most
> > > > of it): I keep my platforms under version control, so a _rm+add_ can
> be
> > > > managed and brought back to what I expect the platform to be in the
> > end.
> > > > However, I do disagree in removing the concept of updates to the
> > > platfroms,
> > > > even if it's only android.
> > > >
> > > > Cordova has come a long way up to try and make the platforms pure
> > > artifacts
> > > > and output from a build process, but the thing is that in real life,
> an
> > > > application needs much more than what config.xml and it's preferences
> > can
> > > > give. Sometimes (I know it's rare) things go further down the line to
> > > > changes in native code, something that cordova's shell can't offer.
> > > > Even if it was a simple application that didn't need any changes in
> the
> > > > native shell, somethings needed for a release are not configurable in
> > > > config.xml, like the keystore info for android, the certificates and
> > > > provisioning profiles in ios (which is a hell to config and get
> > working),
> > > > and stuff like that would have to be reconfigured after an update.
> > > >
> > >
> > > Are these things that writing a plugin cannot solve? Is modifying
> > > platforms/ directly just easier or fundamentally required? Perhaps the
> > > solution is to make plugin development easier (its currently a pain),
> and
> > > to improve our messaging.
> > >
> >
> > There's things that go beyond plugins, but with hooks I think you can
> treat
> > it as an artifact.
> >
> > Reason I think we should advice "platform rm && platform add" is that it
> > gives a warning that what they are about to do is destructive.
> >
> >
> > >
> > >
> > > >
> > > > To sum it up: having my platform folders completely rebuilt against
> my
> > > will
> > > > on platform updates isn't a bad thing IN MY CASE, because I keep it
> > under
> > > > version control and therefore I have control over the changes in the
> > end,
> > > > however I'd prefer to have it be a separate command or an arg I could
> > > pass
> > > > to "platform update". I'd like to have the update process improved
> and
> > > > maintained, but if it's not a priority I can live without it. I have
> > > lived
> > > > like that from 1.7 to 2.9.1, I can do it again :).
> > > >
> > > > 2014-10-01 23:03 GMT-03:00 Michal Mocny <mm...@chromium.org>:
> > > >
> > > > > I like Josh's suggestion to leave the upgrade command in, even if
> it
> > > just
> > > > > maps to remove & add (for the record, we do this for cca). I also
> > > agree
> > > > > with Tommy's concern that we shouldn't remove blindly (for the
> > record,
> > > in
> > > > > cca we warn and prompt for input that it will remove everything
> > first).
> > > > >
> > > > > For those that don't treat platforms as artefacts, it seems not
> > > uncommon
> > > > to
> > > > > keep platforms in version control -- in which case this new type of
> > > > upgrade
> > > > > should not be dangerous or anything.
> > > > >
> > > > > -Michal
> > > > >
> > > > > On Wed, Oct 1, 2014 at 9:31 PM, Tommy Williams <tommy@devgeeks.org
> >
> > > > wrote:
> > > > >
> > > > > > Have we reached the point where ./platforms is a build artefact
> > yet?
> > > > > >
> > > > > > If not, what is remaining?
> > > > > >
> > > > > > If we just removed their android platform and called it upgrade,
> I
> > > > > suspect
> > > > > > some people would lose work on their app.
> > > > > > On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> > > > > >
> > > > > > > There's been a couple bugs come in for Android where our update
> > > > script
> > > > > > has
> > > > > > > failed to bring a project in line with what would be created
> for
> > a
> > > > new
> > > > > > > project: CB-7683, CB-6772
> > > > > > >
> > > > > > > We could put more effort into writing transformations into the
> > > update
> > > > > > > script, but I think it might be more pragmatic to just tell
> > people
> > > to
> > > > > > > "platform rm android && platform add android".
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Frederico Galvão*
> > > >
> > > > Diretor de Tecnologia
> > > >
> > > > PontoGet Inovação Web
> > > >
> > > >
> > > > ( +55(62) 8131-5720
> > > >
> > > > * www.pontoget.com.br <http://www.pontoget.com/>
> > > >
> > >
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Frederico Galvão <fr...@pontoget.com.br>.
Release build configuration (keystore, provisioning profiles) isn't
something that plugins can or should do.
Hooks could do the job indeed, as portrayed in some of http://devgirl.org/
posts, but I found it easier and safer to keep it under version control.
That has had another side effect (a good one) that I wouldn't get from
hooks, which is to know exactly what is generated and inferred by cordova
as the result artifact application.
Things such as
android:installLocation, android:windowSoftInputMode,
android:hardwareAccelerated,
unrequired feature permissions, android:configChanges, android:launchMode,
I would have taken much longer to realize what those are, and I'd probably
realize it with an undesired behaviour at production time.
Unfortunately cordova hasn't filled enough links in configuration from
config.xml to the artifacts for me to blindly believe it has taken all the
best decisions for me. It's on the way towards this point, but not there
yet. That's why I still can't consider the platforms as pure artifacts.
And as I said, Andrew, I'm aware of the destructive nature of such
procedure, and that's why I still have them under version control: so that
I can take care of changes closely. A project or team that doesn't change
anything in platforms manually (or doesn't even know how to do it) will
probably never have any issues with that.
2014-10-02 12:36 GMT-03:00 Andrew Grieve <ag...@chromium.org>:
> On Thu, Oct 2, 2014 at 11:21 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Thu, Oct 2, 2014 at 11:07 AM, Frederico Galvão <
> > frederico.galvao@pontoget.com.br> wrote:
> >
> > > I fall in the scenario described by Tommy, but Michael said "it all"
> > (most
> > > of it): I keep my platforms under version control, so a _rm+add_ can be
> > > managed and brought back to what I expect the platform to be in the
> end.
> > > However, I do disagree in removing the concept of updates to the
> > platfroms,
> > > even if it's only android.
> > >
> > > Cordova has come a long way up to try and make the platforms pure
> > artifacts
> > > and output from a build process, but the thing is that in real life, an
> > > application needs much more than what config.xml and it's preferences
> can
> > > give. Sometimes (I know it's rare) things go further down the line to
> > > changes in native code, something that cordova's shell can't offer.
> > > Even if it was a simple application that didn't need any changes in the
> > > native shell, somethings needed for a release are not configurable in
> > > config.xml, like the keystore info for android, the certificates and
> > > provisioning profiles in ios (which is a hell to config and get
> working),
> > > and stuff like that would have to be reconfigured after an update.
> > >
> >
> > Are these things that writing a plugin cannot solve? Is modifying
> > platforms/ directly just easier or fundamentally required? Perhaps the
> > solution is to make plugin development easier (its currently a pain), and
> > to improve our messaging.
> >
>
> There's things that go beyond plugins, but with hooks I think you can treat
> it as an artifact.
>
> Reason I think we should advice "platform rm && platform add" is that it
> gives a warning that what they are about to do is destructive.
>
>
> >
> >
> > >
> > > To sum it up: having my platform folders completely rebuilt against my
> > will
> > > on platform updates isn't a bad thing IN MY CASE, because I keep it
> under
> > > version control and therefore I have control over the changes in the
> end,
> > > however I'd prefer to have it be a separate command or an arg I could
> > pass
> > > to "platform update". I'd like to have the update process improved and
> > > maintained, but if it's not a priority I can live without it. I have
> > lived
> > > like that from 1.7 to 2.9.1, I can do it again :).
> > >
> > > 2014-10-01 23:03 GMT-03:00 Michal Mocny <mm...@chromium.org>:
> > >
> > > > I like Josh's suggestion to leave the upgrade command in, even if it
> > just
> > > > maps to remove & add (for the record, we do this for cca). I also
> > agree
> > > > with Tommy's concern that we shouldn't remove blindly (for the
> record,
> > in
> > > > cca we warn and prompt for input that it will remove everything
> first).
> > > >
> > > > For those that don't treat platforms as artefacts, it seems not
> > uncommon
> > > to
> > > > keep platforms in version control -- in which case this new type of
> > > upgrade
> > > > should not be dangerous or anything.
> > > >
> > > > -Michal
> > > >
> > > > On Wed, Oct 1, 2014 at 9:31 PM, Tommy Williams <to...@devgeeks.org>
> > > wrote:
> > > >
> > > > > Have we reached the point where ./platforms is a build artefact
> yet?
> > > > >
> > > > > If not, what is remaining?
> > > > >
> > > > > If we just removed their android platform and called it upgrade, I
> > > > suspect
> > > > > some people would lose work on their app.
> > > > > On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > > >
> > > > > > There's been a couple bugs come in for Android where our update
> > > script
> > > > > has
> > > > > > failed to bring a project in line with what would be created for
> a
> > > new
> > > > > > project: CB-7683, CB-6772
> > > > > >
> > > > > > We could put more effort into writing transformations into the
> > update
> > > > > > script, but I think it might be more pragmatic to just tell
> people
> > to
> > > > > > "platform rm android && platform add android".
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Frederico Galvão*
> > >
> > > Diretor de Tecnologia
> > >
> > > PontoGet Inovação Web
> > >
> > >
> > > ( +55(62) 8131-5720
> > >
> > > * www.pontoget.com.br <http://www.pontoget.com/>
> > >
> >
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Oct 2, 2014 at 11:21 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Thu, Oct 2, 2014 at 11:07 AM, Frederico Galvão <
> frederico.galvao@pontoget.com.br> wrote:
>
> > I fall in the scenario described by Tommy, but Michael said "it all"
> (most
> > of it): I keep my platforms under version control, so a _rm+add_ can be
> > managed and brought back to what I expect the platform to be in the end.
> > However, I do disagree in removing the concept of updates to the
> platfroms,
> > even if it's only android.
> >
> > Cordova has come a long way up to try and make the platforms pure
> artifacts
> > and output from a build process, but the thing is that in real life, an
> > application needs much more than what config.xml and it's preferences can
> > give. Sometimes (I know it's rare) things go further down the line to
> > changes in native code, something that cordova's shell can't offer.
> > Even if it was a simple application that didn't need any changes in the
> > native shell, somethings needed for a release are not configurable in
> > config.xml, like the keystore info for android, the certificates and
> > provisioning profiles in ios (which is a hell to config and get working),
> > and stuff like that would have to be reconfigured after an update.
> >
>
> Are these things that writing a plugin cannot solve? Is modifying
> platforms/ directly just easier or fundamentally required? Perhaps the
> solution is to make plugin development easier (its currently a pain), and
> to improve our messaging.
>
There's things that go beyond plugins, but with hooks I think you can treat
it as an artifact.
Reason I think we should advice "platform rm && platform add" is that it
gives a warning that what they are about to do is destructive.
>
>
> >
> > To sum it up: having my platform folders completely rebuilt against my
> will
> > on platform updates isn't a bad thing IN MY CASE, because I keep it under
> > version control and therefore I have control over the changes in the end,
> > however I'd prefer to have it be a separate command or an arg I could
> pass
> > to "platform update". I'd like to have the update process improved and
> > maintained, but if it's not a priority I can live without it. I have
> lived
> > like that from 1.7 to 2.9.1, I can do it again :).
> >
> > 2014-10-01 23:03 GMT-03:00 Michal Mocny <mm...@chromium.org>:
> >
> > > I like Josh's suggestion to leave the upgrade command in, even if it
> just
> > > maps to remove & add (for the record, we do this for cca). I also
> agree
> > > with Tommy's concern that we shouldn't remove blindly (for the record,
> in
> > > cca we warn and prompt for input that it will remove everything first).
> > >
> > > For those that don't treat platforms as artefacts, it seems not
> uncommon
> > to
> > > keep platforms in version control -- in which case this new type of
> > upgrade
> > > should not be dangerous or anything.
> > >
> > > -Michal
> > >
> > > On Wed, Oct 1, 2014 at 9:31 PM, Tommy Williams <to...@devgeeks.org>
> > wrote:
> > >
> > > > Have we reached the point where ./platforms is a build artefact yet?
> > > >
> > > > If not, what is remaining?
> > > >
> > > > If we just removed their android platform and called it upgrade, I
> > > suspect
> > > > some people would lose work on their app.
> > > > On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > >
> > > > > There's been a couple bugs come in for Android where our update
> > script
> > > > has
> > > > > failed to bring a project in line with what would be created for a
> > new
> > > > > project: CB-7683, CB-6772
> > > > >
> > > > > We could put more effort into writing transformations into the
> update
> > > > > script, but I think it might be more pragmatic to just tell people
> to
> > > > > "platform rm android && platform add android".
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Frederico Galvão*
> >
> > Diretor de Tecnologia
> >
> > PontoGet Inovação Web
> >
> >
> > ( +55(62) 8131-5720
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Oct 2, 2014 at 11:07 AM, Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:
> I fall in the scenario described by Tommy, but Michael said "it all" (most
> of it): I keep my platforms under version control, so a _rm+add_ can be
> managed and brought back to what I expect the platform to be in the end.
> However, I do disagree in removing the concept of updates to the platfroms,
> even if it's only android.
>
> Cordova has come a long way up to try and make the platforms pure artifacts
> and output from a build process, but the thing is that in real life, an
> application needs much more than what config.xml and it's preferences can
> give. Sometimes (I know it's rare) things go further down the line to
> changes in native code, something that cordova's shell can't offer.
> Even if it was a simple application that didn't need any changes in the
> native shell, somethings needed for a release are not configurable in
> config.xml, like the keystore info for android, the certificates and
> provisioning profiles in ios (which is a hell to config and get working),
> and stuff like that would have to be reconfigured after an update.
>
Are these things that writing a plugin cannot solve? Is modifying
platforms/ directly just easier or fundamentally required? Perhaps the
solution is to make plugin development easier (its currently a pain), and
to improve our messaging.
>
> To sum it up: having my platform folders completely rebuilt against my will
> on platform updates isn't a bad thing IN MY CASE, because I keep it under
> version control and therefore I have control over the changes in the end,
> however I'd prefer to have it be a separate command or an arg I could pass
> to "platform update". I'd like to have the update process improved and
> maintained, but if it's not a priority I can live without it. I have lived
> like that from 1.7 to 2.9.1, I can do it again :).
>
> 2014-10-01 23:03 GMT-03:00 Michal Mocny <mm...@chromium.org>:
>
> > I like Josh's suggestion to leave the upgrade command in, even if it just
> > maps to remove & add (for the record, we do this for cca). I also agree
> > with Tommy's concern that we shouldn't remove blindly (for the record, in
> > cca we warn and prompt for input that it will remove everything first).
> >
> > For those that don't treat platforms as artefacts, it seems not uncommon
> to
> > keep platforms in version control -- in which case this new type of
> upgrade
> > should not be dangerous or anything.
> >
> > -Michal
> >
> > On Wed, Oct 1, 2014 at 9:31 PM, Tommy Williams <to...@devgeeks.org>
> wrote:
> >
> > > Have we reached the point where ./platforms is a build artefact yet?
> > >
> > > If not, what is remaining?
> > >
> > > If we just removed their android platform and called it upgrade, I
> > suspect
> > > some people would lose work on their app.
> > > On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > > > There's been a couple bugs come in for Android where our update
> script
> > > has
> > > > failed to bring a project in line with what would be created for a
> new
> > > > project: CB-7683, CB-6772
> > > >
> > > > We could put more effort into writing transformations into the update
> > > > script, but I think it might be more pragmatic to just tell people to
> > > > "platform rm android && platform add android".
> > > >
> > > > Thoughts?
> > > >
> > >
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Frederico Galvão <fr...@pontoget.com.br>.
I fall in the scenario described by Tommy, but Michael said "it all" (most
of it): I keep my platforms under version control, so a _rm+add_ can be
managed and brought back to what I expect the platform to be in the end.
However, I do disagree in removing the concept of updates to the platfroms,
even if it's only android.
Cordova has come a long way up to try and make the platforms pure artifacts
and output from a build process, but the thing is that in real life, an
application needs much more than what config.xml and it's preferences can
give. Sometimes (I know it's rare) things go further down the line to
changes in native code, something that cordova's shell can't offer.
Even if it was a simple application that didn't need any changes in the
native shell, somethings needed for a release are not configurable in
config.xml, like the keystore info for android, the certificates and
provisioning profiles in ios (which is a hell to config and get working),
and stuff like that would have to be reconfigured after an update.
To sum it up: having my platform folders completely rebuilt against my will
on platform updates isn't a bad thing IN MY CASE, because I keep it under
version control and therefore I have control over the changes in the end,
however I'd prefer to have it be a separate command or an arg I could pass
to "platform update". I'd like to have the update process improved and
maintained, but if it's not a priority I can live without it. I have lived
like that from 1.7 to 2.9.1, I can do it again :).
2014-10-01 23:03 GMT-03:00 Michal Mocny <mm...@chromium.org>:
> I like Josh's suggestion to leave the upgrade command in, even if it just
> maps to remove & add (for the record, we do this for cca). I also agree
> with Tommy's concern that we shouldn't remove blindly (for the record, in
> cca we warn and prompt for input that it will remove everything first).
>
> For those that don't treat platforms as artefacts, it seems not uncommon to
> keep platforms in version control -- in which case this new type of upgrade
> should not be dangerous or anything.
>
> -Michal
>
> On Wed, Oct 1, 2014 at 9:31 PM, Tommy Williams <to...@devgeeks.org> wrote:
>
> > Have we reached the point where ./platforms is a build artefact yet?
> >
> > If not, what is remaining?
> >
> > If we just removed their android platform and called it upgrade, I
> suspect
> > some people would lose work on their app.
> > On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> > > There's been a couple bugs come in for Android where our update script
> > has
> > > failed to bring a project in line with what would be created for a new
> > > project: CB-7683, CB-6772
> > >
> > > We could put more effort into writing transformations into the update
> > > script, but I think it might be more pragmatic to just tell people to
> > > "platform rm android && platform add android".
> > >
> > > Thoughts?
> > >
> >
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Michal Mocny <mm...@chromium.org>.
I like Josh's suggestion to leave the upgrade command in, even if it just
maps to remove & add (for the record, we do this for cca). I also agree
with Tommy's concern that we shouldn't remove blindly (for the record, in
cca we warn and prompt for input that it will remove everything first).
For those that don't treat platforms as artefacts, it seems not uncommon to
keep platforms in version control -- in which case this new type of upgrade
should not be dangerous or anything.
-Michal
On Wed, Oct 1, 2014 at 9:31 PM, Tommy Williams <to...@devgeeks.org> wrote:
> Have we reached the point where ./platforms is a build artefact yet?
>
> If not, what is remaining?
>
> If we just removed their android platform and called it upgrade, I suspect
> some people would lose work on their app.
> On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> > There's been a couple bugs come in for Android where our update script
> has
> > failed to bring a project in line with what would be created for a new
> > project: CB-7683, CB-6772
> >
> > We could put more effort into writing transformations into the update
> > script, but I think it might be more pragmatic to just tell people to
> > "platform rm android && platform add android".
> >
> > Thoughts?
> >
>
Re: [DISCUSS] Deprecate "platform update" command?
Posted by Tommy Williams <to...@devgeeks.org>.
Have we reached the point where ./platforms is a build artefact yet?
If not, what is remaining?
If we just removed their android platform and called it upgrade, I suspect
some people would lose work on their app.
On 2 Oct 2014 11:18, "Andrew Grieve" <ag...@chromium.org> wrote:
> There's been a couple bugs come in for Android where our update script has
> failed to bring a project in line with what would be created for a new
> project: CB-7683, CB-6772
>
> We could put more effort into writing transformations into the update
> script, but I think it might be more pragmatic to just tell people to
> "platform rm android && platform add android".
>
> Thoughts?
>