cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frederico Galvão <frederico.gal...@pontoget.com.br>
Subject Re: [DISCUSS] Deprecate "platform update" command?
Date Thu, 02 Oct 2014 16:12:32 GMT
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 <agrieve@chromium.org>:

> On Thu, Oct 2, 2014 at 11:21 AM, Michal Mocny <mmocny@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 <mmocny@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" <agrieve@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/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message