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 < [email protected]> 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 <[email protected]>: > > > On Thu, Oct 2, 2014 at 11:21 AM, Michal Mocny <[email protected]> > wrote: > > > > > On Thu, Oct 2, 2014 at 11:07 AM, Frederico Galvão < > > > [email protected]> 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 <[email protected]>: > > > > > > > > > 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 <[email protected] > > > > > > 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" <[email protected]> > 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/> >
