cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: [DISCUSS] Deprecate "platform update" command?
Date Thu, 02 Oct 2014 15:21:48 GMT
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 <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/>
>

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