cordova-dev mailing list archives

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

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