Plugin Version Control Workflow

[Ross Gerbasi <rg...@gmail.com>]

Hey Gang,

I think we need a better way to manage plugins across teams. I imagine we
don't want people checking the plugins folder into version control, I would
also think platforms should be ignored also. What do you all think about
some kind of plugin manifest file and a install command. Something like
nodes package.jsonn and npm install?

Re: Plugin Version Control Workflow

[Brian LeRoux <b...@brian.io>]

All contributions are welcome.

Consider language about priority as committer boundaries that may or may
not have broad support or be related to sponsoring companies downstream
distribution priorities.

But ultimately, this is an Apache project and stuff happens when people do
it.


On Tue, Jan 7, 2014 at 3:14 AM, Andrey Kurdumov <ka...@googlemail.com>wrote:

> Dan, Ross.
>
> I complexly agree with both of you. My workflow - my problems. I wrote
> about it just so you have background about needs of developers like me.
> When I read about number 99% CLI developers, I understand that I am from
> the not mentioned 1%. And tone of the discussion for me sounds like that 1%
> would not be taken into consideration.
>
> Right now I have 2 small issues which would be important for you only if
> you keep you ./plugins, ./platforms source code in VCS. Don't think that
> they are valuable enough for you when you main use-case is keep ./plugins
> and ./platforms outside of VCS, so I better implement them myself and
> contribute back to the Cordova.
>
> What is not clear to me, are such contributions would be welcome or not,
> since it is for only 1% of people?
>
> Andrey K.
>
>
>
> 2014/1/7 Ross Gerbasi <rg...@gmail.com>
>
> > Hey Andrey,
> >
> > Much like you said 99% of the users will want to ignore platforms and
> > plugins from version control. Making this work properly would not stop
> > someone from including them if they wanted to. If your workflow is better
> > including those folders you would have no problem doing so.
> >
> > Ideally though if you can keep your custom code off in plugins, even if
> > they are not public plugins, would be ideal. Also as Dan mentioned you
> can
> > look into hooks to help modify platforms as needed.
> >
> > Again though if you find checking everything in easier thats cool but the
> > CLI should be setup in a way that we do not need to.
> >
> >
> >
> > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com> wrote:
> >
> > > Hi Andrey,
> > >
> > > I have worked on two small, simple Cordova applications, but we still
> at
> > > times had to modify platform specific code.  Not much, but some
> > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > Android--this
> > > is a 2.9.x project for now).
> > >
> > > Here's my solutions to your issues.
> > > * if you need to modify native plugin code, you should fork the repo
> and
> > > manage your changes via a git project, not in your project.
> > >
> > > If you use a recent enough version of Cordova, you can even pull
> plugins
> > > off git branches ( see https://issues.apache.org/jira/browse/CB-4981 )
> > so
> > > you could have different versions of your apps for different clients
> pull
> > > different branches of the same plugin.
> > >
> > > * if you need to modify code under platforms, use an after_platform_add
> > > hook, and keep your customized platform files elsewhere in your project
> > > tree.
> > >
> > > This way, you aren't version controlling everything, just what you've
> had
> > > to change.  Of course, when the Cordova platform changes underneath you
> > > (perhaps a new method is added to AppDelegate.m, and the version you
> have
> > > in source control overwrites that), you need to check these files
> > > carefully.  But when you version control everything and you upgrade,
> you
> > > have to merge in your custom changes into the new Cordova code in the
> > same
> > > careful manner, plus you are carrying around everything else under
> > > platforms.
> > >
> > > Of course, I'm a big believer in the CLI, having everyone use the
> entire
> > > CLI toolchain, and treating everything under platforms and plugins as
> > > derived code that you can replace at any time.  If this isn't how you
> > > develop (if you prefer the 'native project dev' workflow, for example),
> > > then this may not work for you.
> > >
> > > Thanks.
> > > Dan
> > >
> > > PS Can you explain how keeping all the code in source control makes
> your
> > > merges as you move from Cordova version to Cordova version easier?  To
> > me,
> > > that would seem to make them more difficult.
> > >
> > >
> > >
> > >
> > >
> > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > kant2002@googlemail.com> wrote:
> > >
> > > About plugin and platform version control.
> > > I heard a lot about that, and confused why you think that everybody
> would
> > > like to remove ./plugins and ./platforms folders from source control. I
> > do
> > > agree that this is most likely the case for the simple applications and
> > for
> > > the maybe 99% of current Cordova users, but I don't believe that this
> is
> > > truly important for the Cordova as the ecosystem for the cross-platform
> > of
> > > the mobile development.
> > >
> > > Let me explain why I think that keep ./platforms and ./plugins under
> > source
> > > control very important. I would base my reasoning on my current project
> > > needs.
> > > I currently develop 2 similar products for different clients from the
> > same
> > > domain. I understand that in future I will have another clients from
> same
> > > problem domain which would like to have similar applications, just with
> > > different design. So I take the route of having 1 product line and
> > > customization of that product line for each client, depends on their
> > needs.
> > > This is client facing application, so I would like to cover as much
> > mobile
> > > platforms as possible with minimum amount of efforts. Currently I
> support
> > > only Android and iOS platforms, but envision that my clients will
> expand
> > to
> > > the Windows Phone soon, and maybe I will force them to support Tizen in
> > > next year if that platform would be world-wide popular.
> > > I position my self as
> > > a) heavy Cordova user
> > > b) middle/low platform specific development. (I have to go deep in each
> > > platform, but that's not priority for me as Cordova users)
> > > I maintain 3 Git branches. 1 branch for core product and 2 branches for
> > > each client. In each branch I keep, platform specific code for the
> > > application (cordova-platform-ios/android code), Cordova plugins code +
> > > plugins developed specifically to this application.
> > > I definitely sure that I will need to add some functionality to the
> core
> > > platforms, either iOS or Android which will benefit the my
> application. I
> > > would try to push to the core Cordova as much as I can, but possible
> that
> > > not all contribution would be useful for the Cordova. Either way I plan
> > for
> > > update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> > > changes, which I add to current version of Cordova (3.3) and make
> update
> > to
> > > 3.4 and later easier I keep all code in the source control to make all
> my
> > > future merges easier. Same rules apply to the plugins,maybe I add some
> > > code/fixes to plugins, or not don't matter - I have to plan for that.
> > > I would like to contribute to Cordova everything what will benefit the
> > > community to meet my selfish goals:
> > > I want to make my upgrade path as straightforward as possible, for
> > platform
> > > code and for plugins code.
> > >
> > > Maybe I was too verbose, but that was just to explain that I plan to
> > align
> > > my long-term goals with Cordova's long-term goals. I try to gave more
> > > explanation, so you guys could plan not only for people which create
> > > projects which are working on the specific version of Cordova, but also
> > for
> > > the guys which want to nurture their product together with Cordova.
> > >
> > > I plainly don't see:
> > > a) how I could work on my product not keeping ./platforms and ./plugins
> > > directories in the source control, and
> > > b) why I should don't use Cordova CLI to update contents of my
> > ./platforms
> > > and ./plugins folders. I think that these tool has a good fit for basic
> > > housekeeping of the files/plugins. Don't want to manually fiddle with
> > > content of plugins for each platform and use plugman/cordova
> executables
> > to
> > > do the job.
> > >
> > > Hopefully I was enough verbose to explain why I have needs what I have
> > now,
> > > and not too verbose so you flood in details.
> > >
> > > To summarize my input is:
> > > 1. Keep tools that way, that it could work either when ./plugins,
> > > ./platforms in source control, or when these folders not in the VCS.
> > > 2. Take into account that people may want to customize Cordova
> > distribution
> > > and have path to future upgrades.
> > > 3. I want to take responsibility for some burden which this way could
> > > potentially create for you guys,
> > >
> > > Andrey Kurdyumov.
> > >
> > >
> > >
> > >
> > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > >
> > > > I've wanted to add Cordova plugin dependencies to the app's top-level
> > > > config.xml for a long time, but it's never reached the top of my
> > > > priorities. I think with that support, we can avoid checking in
> > > ./plugins/
> > > > and ./platforms altogether for 99% of app developers. If it doesn't
> > solve
> > > > anyone's use case, I'd love to hear about it.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com>
> > > wrote:
> > > >
> > > > > CB-4624 is exactly what I am looking for. I am not sure if it
> should
> > be
> > > > > config.xml or some other config file, it probably doesn't matter
> much
> > > > when
> > > > > it comes down to it. Is there any rules currently in place, like
> CLI
> > > > > doesn't touch config.xml?
> > > > >
> > > > >
> > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > agrieve@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> > > relevant
> > > > > > issue
> > > > > > here. Please add comments to it if it's not spec'ed or good
> enough.
> > > > > >
> > > > > > Also related is https://issues.apache.org/jira/browse/CB-5006 -
> > > meant
> > > > to
> > > > > > address local repos of plugins.
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > kant2002@googlemail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Would be very helpful if you change formatting of the plugins
> > > > manifest
> > > > > > > files (android.json, ios.json). Currently it is print all JSON
> > > string
> > > > > to
> > > > > > > the big single line, which difficult to merge when needed.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Carlos Santana <cs...@gmail.com>]

+1 on emulating node/npm

"cordova install" reads cordova.json or cordova section of package.json
(which contains all dependencies for plugins and platforms) to download and
add from heaven (oops I meant the cloud :-) )



On Tue, Jan 7, 2014 at 1:33 PM, Brian LeRoux <b...@brian.io> wrote:

> we may want to emulate node/npm here
>
> `npm install`
>
>
> On Tue, Jan 7, 2014 at 10:20 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Definitely a config.xml thing.
> >
> > I don't think anyone's fiddling. If you want to take it on, that'd be
> > awesome. Mark the issue as assigned to yourself (just gave you JIRA
> perms)
> > and have at it! :)
> >
> > Idea for implementing this:
> > 1. Get "cordova plugin add" at add a <dependency> tag to config.xml
> > 2. Add a "cordova plugin sync" command that adds/removes plugins based on
> > what's in config.xml
> >
> >
> >
> > On Tue, Jan 7, 2014 at 9:12 AM, Ross Gerbasi <rg...@gmail.com> wrote:
> >
> > > Sooooo I think we are all cool on this. Adding this feature does not
> stop
> > > anyone from checking in those folders if they desire.
> > >
> > > How can I help make this happen? Or is someone already fiddling with
> > this?
> > > Last activity on the issue was a month ago (
> > > https://issues.apache.org/jira/browse/CB-4624)
> > >
> > > Then again does this still require some choices to be made? I know
> there
> > is
> > > a lot of talk of config.xml and cordova.json and what goes where but I
> am
> > > assuming this is a config.xml thing.
> > >
> > >
> > > On Tue, Jan 7, 2014 at 11:03 AM, Braden Shepherdson <
> braden@chromium.org
> > > >wrote:
> > >
> > > > I think we're talking somewhat at cross purposes.
> > > >
> > > > One of my goals with the CLI is to make the ./platforms and ./plugins
> > > > directories build artifacts, meaning that you could delete them (or
> > check
> > > > out a new copy of your project that does not include them) and
> restore
> > > them
> > > > fully with a couple of commands.
> > > >
> > > > Currently the two commands would have to be: cordova platform add
> <all
> > > your
> > > > platforms> and cordova plugin add <all your plugins>. The latter is
> > > > unfortunately long, and we hope to fix that by allowing you to
> specify
> > > > required plugins for the project in the top-level app config.xml
> file,
> > so
> > > > that the second command becomes simply "cordova plugin add" or
> "cordova
> > > > plugin add --deps" or whatever we decide it should be.
> > > >
> > > > Why I say we're talking at cross purposes is that there's nothing
> about
> > > any
> > > > of this that stops people from checking some or all of the
> ./platforms
> > > > directory into their source control. They'll have to spend some
> effort
> > > > maintaining it, as Cordova updates various files, but that's the case
> > if
> > > > you have custom edits to the native code whether you put it in
> version
> > > > control or not.
> > > >
> > > > I mention the 99% of Cordova users because at some point it becomes
> > > > impractical to support 100% with the tool. There's always going to be
> > > some
> > > > esoteric use cases that will require some hand-holding to work with
> the
> > > > CLI.
> > > >
> > > > We have tried to extract most of the things that used to require
> tweaks
> > > to
> > > > the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into
> > > preferences
> > > > that can be set from config files. If there are tweaks that are
> needed
> > by
> > > > more than a few users and are not covered by preferences, then they
> > > should
> > > > be added as new preferences.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <
> > kant2002@googlemail.com
> > > > >wrote:
> > > >
> > > > > Dan, Ross.
> > > > >
> > > > > I complexly agree with both of you. My workflow - my problems. I
> > wrote
> > > > > about it just so you have background about needs of developers like
> > me.
> > > > > When I read about number 99% CLI developers, I understand that I am
> > > from
> > > > > the not mentioned 1%. And tone of the discussion for me sounds like
> > > that
> > > > 1%
> > > > > would not be taken into consideration.
> > > > >
> > > > > Right now I have 2 small issues which would be important for you
> only
> > > if
> > > > > you keep you ./plugins, ./platforms source code in VCS. Don't think
> > > that
> > > > > they are valuable enough for you when you main use-case is keep
> > > ./plugins
> > > > > and ./platforms outside of VCS, so I better implement them myself
> and
> > > > > contribute back to the Cordova.
> > > > >
> > > > > What is not clear to me, are such contributions would be welcome or
> > > not,
> > > > > since it is for only 1% of people?
> > > > >
> > > > > Andrey K.
> > > > >
> > > > >
> > > > >
> > > > > 2014/1/7 Ross Gerbasi <rg...@gmail.com>
> > > > >
> > > > > > Hey Andrey,
> > > > > >
> > > > > > Much like you said 99% of the users will want to ignore platforms
> > and
> > > > > > plugins from version control. Making this work properly would not
> > > stop
> > > > > > someone from including them if they wanted to. If your workflow
> is
> > > > better
> > > > > > including those folders you would have no problem doing so.
> > > > > >
> > > > > > Ideally though if you can keep your custom code off in plugins,
> > even
> > > if
> > > > > > they are not public plugins, would be ideal. Also as Dan
> mentioned
> > > you
> > > > > can
> > > > > > look into hooks to help modify platforms as needed.
> > > > > >
> > > > > > Again though if you find checking everything in easier thats cool
> > but
> > > > the
> > > > > > CLI should be setup in a way that we do not need to.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com>
> > > wrote:
> > > > > >
> > > > > > > Hi Andrey,
> > > > > > >
> > > > > > > I have worked on two small, simple Cordova applications, but we
> > > still
> > > > > at
> > > > > > > times had to modify platform specific code.  Not much, but some
> > > > > > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > > > > > Android--this
> > > > > > > is a 2.9.x project for now).
> > > > > > >
> > > > > > > Here's my solutions to your issues.
> > > > > > > * if you need to modify native plugin code, you should fork the
> > > repo
> > > > > and
> > > > > > > manage your changes via a git project, not in your project.
> > > > > > >
> > > > > > > If you use a recent enough version of Cordova, you can even
> pull
> > > > > plugins
> > > > > > > off git branches ( see
> > > https://issues.apache.org/jira/browse/CB-4981)
> > > > > > so
> > > > > > > you could have different versions of your apps for different
> > > clients
> > > > > pull
> > > > > > > different branches of the same plugin.
> > > > > > >
> > > > > > > * if you need to modify code under platforms, use an
> > > > after_platform_add
> > > > > > > hook, and keep your customized platform files elsewhere in your
> > > > project
> > > > > > > tree.
> > > > > > >
> > > > > > > This way, you aren't version controlling everything, just what
> > > you've
> > > > > had
> > > > > > > to change.  Of course, when the Cordova platform changes
> > underneath
> > > > you
> > > > > > > (perhaps a new method is added to AppDelegate.m, and the
> version
> > > you
> > > > > have
> > > > > > > in source control overwrites that), you need to check these
> files
> > > > > > > carefully.  But when you version control everything and you
> > > upgrade,
> > > > > you
> > > > > > > have to merge in your custom changes into the new Cordova code
> in
> > > the
> > > > > > same
> > > > > > > careful manner, plus you are carrying around everything else
> > under
> > > > > > > platforms.
> > > > > > >
> > > > > > > Of course, I'm a big believer in the CLI, having everyone use
> the
> > > > > entire
> > > > > > > CLI toolchain, and treating everything under platforms and
> > plugins
> > > as
> > > > > > > derived code that you can replace at any time.  If this isn't
> how
> > > you
> > > > > > > develop (if you prefer the 'native project dev' workflow, for
> > > > example),
> > > > > > > then this may not work for you.
> > > > > > >
> > > > > > > Thanks.
> > > > > > > Dan
> > > > > > >
> > > > > > > PS Can you explain how keeping all the code in source control
> > makes
> > > > > your
> > > > > > > merges as you move from Cordova version to Cordova version
> > easier?
> > > >  To
> > > > > > me,
> > > > > > > that would seem to make them more difficult.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > > > > > kant2002@googlemail.com> wrote:
> > > > > > >
> > > > > > > About plugin and platform version control.
> > > > > > > I heard a lot about that, and confused why you think that
> > everybody
> > > > > would
> > > > > > > like to remove ./plugins and ./platforms folders from source
> > > > control. I
> > > > > > do
> > > > > > > agree that this is most likely the case for the simple
> > applications
> > > > and
> > > > > > for
> > > > > > > the maybe 99% of current Cordova users, but I don't believe
> that
> > > this
> > > > > is
> > > > > > > truly important for the Cordova as the ecosystem for the
> > > > cross-platform
> > > > > > of
> > > > > > > the mobile development.
> > > > > > >
> > > > > > > Let me explain why I think that keep ./platforms and ./plugins
> > > under
> > > > > > source
> > > > > > > control very important. I would base my reasoning on my current
> > > > project
> > > > > > > needs.
> > > > > > > I currently develop 2 similar products for different clients
> from
> > > the
> > > > > > same
> > > > > > > domain. I understand that in future I will have another clients
> > > from
> > > > > same
> > > > > > > problem domain which would like to have similar applications,
> > just
> > > > with
> > > > > > > different design. So I take the route of having 1 product line
> > and
> > > > > > > customization of that product line for each client, depends on
> > > their
> > > > > > needs.
> > > > > > > This is client facing application, so I would like to cover as
> > much
> > > > > > mobile
> > > > > > > platforms as possible with minimum amount of efforts.
> Currently I
> > > > > support
> > > > > > > only Android and iOS platforms, but envision that my clients
> will
> > > > > expand
> > > > > > to
> > > > > > > the Windows Phone soon, and maybe I will force them to support
> > > Tizen
> > > > in
> > > > > > > next year if that platform would be world-wide popular.
> > > > > > > I position my self as
> > > > > > > a) heavy Cordova user
> > > > > > > b) middle/low platform specific development. (I have to go deep
> > in
> > > > each
> > > > > > > platform, but that's not priority for me as Cordova users)
> > > > > > > I maintain 3 Git branches. 1 branch for core product and 2
> > branches
> > > > for
> > > > > > > each client. In each branch I keep, platform specific code for
> > the
> > > > > > > application (cordova-platform-ios/android code), Cordova
> plugins
> > > > code +
> > > > > > > plugins developed specifically to this application.
> > > > > > > I definitely sure that I will need to add some functionality to
> > the
> > > > > core
> > > > > > > platforms, either iOS or Android which will benefit the my
> > > > > application. I
> > > > > > > would try to push to the core Cordova as much as I can, but
> > > possible
> > > > > that
> > > > > > > not all contribution would be useful for the Cordova. Either
> way
> > I
> > > > plan
> > > > > > for
> > > > > > > update to next version of Cordova (3.4, or 3.5 whenether). To
> > keep
> > > my
> > > > > > > changes, which I add to current version of Cordova (3.3) and
> make
> > > > > update
> > > > > > to
> > > > > > > 3.4 and later easier I keep all code in the source control to
> > make
> > > > all
> > > > > my
> > > > > > > future merges easier. Same rules apply to the plugins,maybe I
> add
> > > > some
> > > > > > > code/fixes to plugins, or not don't matter - I have to plan for
> > > that.
> > > > > > > I would like to contribute to Cordova everything what will
> > benefit
> > > > the
> > > > > > > community to meet my selfish goals:
> > > > > > > I want to make my upgrade path as straightforward as possible,
> > for
> > > > > > platform
> > > > > > > code and for plugins code.
> > > > > > >
> > > > > > > Maybe I was too verbose, but that was just to explain that I
> plan
> > > to
> > > > > > align
> > > > > > > my long-term goals with Cordova's long-term goals. I try to
> gave
> > > more
> > > > > > > explanation, so you guys could plan not only for people which
> > > create
> > > > > > > projects which are working on the specific version of Cordova,
> > but
> > > > also
> > > > > > for
> > > > > > > the guys which want to nurture their product together with
> > Cordova.
> > > > > > >
> > > > > > > I plainly don't see:
> > > > > > > a) how I could work on my product not keeping ./platforms and
> > > > ./plugins
> > > > > > > directories in the source control, and
> > > > > > > b) why I should don't use Cordova CLI to update contents of my
> > > > > > ./platforms
> > > > > > > and ./plugins folders. I think that these tool has a good fit
> for
> > > > basic
> > > > > > > housekeeping of the files/plugins. Don't want to manually
> fiddle
> > > with
> > > > > > > content of plugins for each platform and use plugman/cordova
> > > > > executables
> > > > > > to
> > > > > > > do the job.
> > > > > > >
> > > > > > > Hopefully I was enough verbose to explain why I have needs
> what I
> > > > have
> > > > > > now,
> > > > > > > and not too verbose so you flood in details.
> > > > > > >
> > > > > > > To summarize my input is:
> > > > > > > 1. Keep tools that way, that it could work either when
> ./plugins,
> > > > > > > ./platforms in source control, or when these folders not in the
> > > VCS.
> > > > > > > 2. Take into account that people may want to customize Cordova
> > > > > > distribution
> > > > > > > and have path to future upgrades.
> > > > > > > 3. I want to take responsibility for some burden which this way
> > > could
> > > > > > > potentially create for you guys,
> > > > > > >
> > > > > > > Andrey Kurdyumov.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > > > > > >
> > > > > > > > I've wanted to add Cordova plugin dependencies to the app's
> > > > top-level
> > > > > > > > config.xml for a long time, but it's never reached the top of
> > my
> > > > > > > > priorities. I think with that support, we can avoid checking
> in
> > > > > > > ./plugins/
> > > > > > > > and ./platforms altogether for 99% of app developers. If it
> > > doesn't
> > > > > > solve
> > > > > > > > anyone's use case, I'd love to hear about it.
> > > > > > > >
> > > > > > > > Braden
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <
> > > rgerbasi@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > CB-4624 is exactly what I am looking for. I am not sure if
> it
> > > > > should
> > > > > > be
> > > > > > > > > config.xml or some other config file, it probably doesn't
> > > matter
> > > > > much
> > > > > > > > when
> > > > > > > > > it comes down to it. Is there any rules currently in place,
> > > like
> > > > > CLI
> > > > > > > > > doesn't touch config.xml?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > > > > > agrieve@chromium.org
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is
> > the
> > > > > > > relevant
> > > > > > > > > > issue
> > > > > > > > > > here. Please add comments to it if it's not spec'ed or
> good
> > > > > enough.
> > > > > > > > > >
> > > > > > > > > > Also related is
> > > https://issues.apache.org/jira/browse/CB-5006-
> > > > > > > meant
> > > > > > > > to
> > > > > > > > > > address local repos of plugins.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > > > > > kant2002@googlemail.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > Would be very helpful if you change formatting of the
> > > plugins
> > > > > > > > manifest
> > > > > > > > > > > files (android.json, ios.json). Currently it is print
> all
> > > > JSON
> > > > > > > string
> > > > > > > > > to
> > > > > > > > > > > the big single line, which difficult to merge when
> > needed.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Plugin Version Control Workflow

[Brian LeRoux <b...@brian.io>]

we may want to emulate node/npm here

`npm install`


On Tue, Jan 7, 2014 at 10:20 AM, Andrew Grieve <ag...@chromium.org> wrote:

> Definitely a config.xml thing.
>
> I don't think anyone's fiddling. If you want to take it on, that'd be
> awesome. Mark the issue as assigned to yourself (just gave you JIRA perms)
> and have at it! :)
>
> Idea for implementing this:
> 1. Get "cordova plugin add" at add a <dependency> tag to config.xml
> 2. Add a "cordova plugin sync" command that adds/removes plugins based on
> what's in config.xml
>
>
>
> On Tue, Jan 7, 2014 at 9:12 AM, Ross Gerbasi <rg...@gmail.com> wrote:
>
> > Sooooo I think we are all cool on this. Adding this feature does not stop
> > anyone from checking in those folders if they desire.
> >
> > How can I help make this happen? Or is someone already fiddling with
> this?
> > Last activity on the issue was a month ago (
> > https://issues.apache.org/jira/browse/CB-4624)
> >
> > Then again does this still require some choices to be made? I know there
> is
> > a lot of talk of config.xml and cordova.json and what goes where but I am
> > assuming this is a config.xml thing.
> >
> >
> > On Tue, Jan 7, 2014 at 11:03 AM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > I think we're talking somewhat at cross purposes.
> > >
> > > One of my goals with the CLI is to make the ./platforms and ./plugins
> > > directories build artifacts, meaning that you could delete them (or
> check
> > > out a new copy of your project that does not include them) and restore
> > them
> > > fully with a couple of commands.
> > >
> > > Currently the two commands would have to be: cordova platform add <all
> > your
> > > platforms> and cordova plugin add <all your plugins>. The latter is
> > > unfortunately long, and we hope to fix that by allowing you to specify
> > > required plugins for the project in the top-level app config.xml file,
> so
> > > that the second command becomes simply "cordova plugin add" or "cordova
> > > plugin add --deps" or whatever we decide it should be.
> > >
> > > Why I say we're talking at cross purposes is that there's nothing about
> > any
> > > of this that stops people from checking some or all of the ./platforms
> > > directory into their source control. They'll have to spend some effort
> > > maintaining it, as Cordova updates various files, but that's the case
> if
> > > you have custom edits to the native code whether you put it in version
> > > control or not.
> > >
> > > I mention the 99% of Cordova users because at some point it becomes
> > > impractical to support 100% with the tool. There's always going to be
> > some
> > > esoteric use cases that will require some hand-holding to work with the
> > > CLI.
> > >
> > > We have tried to extract most of the things that used to require tweaks
> > to
> > > the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into
> > preferences
> > > that can be set from config files. If there are tweaks that are needed
> by
> > > more than a few users and are not covered by preferences, then they
> > should
> > > be added as new preferences.
> > >
> > > Braden
> > >
> > >
> > > On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <
> kant2002@googlemail.com
> > > >wrote:
> > >
> > > > Dan, Ross.
> > > >
> > > > I complexly agree with both of you. My workflow - my problems. I
> wrote
> > > > about it just so you have background about needs of developers like
> me.
> > > > When I read about number 99% CLI developers, I understand that I am
> > from
> > > > the not mentioned 1%. And tone of the discussion for me sounds like
> > that
> > > 1%
> > > > would not be taken into consideration.
> > > >
> > > > Right now I have 2 small issues which would be important for you only
> > if
> > > > you keep you ./plugins, ./platforms source code in VCS. Don't think
> > that
> > > > they are valuable enough for you when you main use-case is keep
> > ./plugins
> > > > and ./platforms outside of VCS, so I better implement them myself and
> > > > contribute back to the Cordova.
> > > >
> > > > What is not clear to me, are such contributions would be welcome or
> > not,
> > > > since it is for only 1% of people?
> > > >
> > > > Andrey K.
> > > >
> > > >
> > > >
> > > > 2014/1/7 Ross Gerbasi <rg...@gmail.com>
> > > >
> > > > > Hey Andrey,
> > > > >
> > > > > Much like you said 99% of the users will want to ignore platforms
> and
> > > > > plugins from version control. Making this work properly would not
> > stop
> > > > > someone from including them if they wanted to. If your workflow is
> > > better
> > > > > including those folders you would have no problem doing so.
> > > > >
> > > > > Ideally though if you can keep your custom code off in plugins,
> even
> > if
> > > > > they are not public plugins, would be ideal. Also as Dan mentioned
> > you
> > > > can
> > > > > look into hooks to help modify platforms as needed.
> > > > >
> > > > > Again though if you find checking everything in easier thats cool
> but
> > > the
> > > > > CLI should be setup in a way that we do not need to.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com>
> > wrote:
> > > > >
> > > > > > Hi Andrey,
> > > > > >
> > > > > > I have worked on two small, simple Cordova applications, but we
> > still
> > > > at
> > > > > > times had to modify platform specific code.  Not much, but some
> > > > > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > > > > Android--this
> > > > > > is a 2.9.x project for now).
> > > > > >
> > > > > > Here's my solutions to your issues.
> > > > > > * if you need to modify native plugin code, you should fork the
> > repo
> > > > and
> > > > > > manage your changes via a git project, not in your project.
> > > > > >
> > > > > > If you use a recent enough version of Cordova, you can even pull
> > > > plugins
> > > > > > off git branches ( see
> > https://issues.apache.org/jira/browse/CB-4981)
> > > > > so
> > > > > > you could have different versions of your apps for different
> > clients
> > > > pull
> > > > > > different branches of the same plugin.
> > > > > >
> > > > > > * if you need to modify code under platforms, use an
> > > after_platform_add
> > > > > > hook, and keep your customized platform files elsewhere in your
> > > project
> > > > > > tree.
> > > > > >
> > > > > > This way, you aren't version controlling everything, just what
> > you've
> > > > had
> > > > > > to change.  Of course, when the Cordova platform changes
> underneath
> > > you
> > > > > > (perhaps a new method is added to AppDelegate.m, and the version
> > you
> > > > have
> > > > > > in source control overwrites that), you need to check these files
> > > > > > carefully.  But when you version control everything and you
> > upgrade,
> > > > you
> > > > > > have to merge in your custom changes into the new Cordova code in
> > the
> > > > > same
> > > > > > careful manner, plus you are carrying around everything else
> under
> > > > > > platforms.
> > > > > >
> > > > > > Of course, I'm a big believer in the CLI, having everyone use the
> > > > entire
> > > > > > CLI toolchain, and treating everything under platforms and
> plugins
> > as
> > > > > > derived code that you can replace at any time.  If this isn't how
> > you
> > > > > > develop (if you prefer the 'native project dev' workflow, for
> > > example),
> > > > > > then this may not work for you.
> > > > > >
> > > > > > Thanks.
> > > > > > Dan
> > > > > >
> > > > > > PS Can you explain how keeping all the code in source control
> makes
> > > > your
> > > > > > merges as you move from Cordova version to Cordova version
> easier?
> > >  To
> > > > > me,
> > > > > > that would seem to make them more difficult.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > > > > kant2002@googlemail.com> wrote:
> > > > > >
> > > > > > About plugin and platform version control.
> > > > > > I heard a lot about that, and confused why you think that
> everybody
> > > > would
> > > > > > like to remove ./plugins and ./platforms folders from source
> > > control. I
> > > > > do
> > > > > > agree that this is most likely the case for the simple
> applications
> > > and
> > > > > for
> > > > > > the maybe 99% of current Cordova users, but I don't believe that
> > this
> > > > is
> > > > > > truly important for the Cordova as the ecosystem for the
> > > cross-platform
> > > > > of
> > > > > > the mobile development.
> > > > > >
> > > > > > Let me explain why I think that keep ./platforms and ./plugins
> > under
> > > > > source
> > > > > > control very important. I would base my reasoning on my current
> > > project
> > > > > > needs.
> > > > > > I currently develop 2 similar products for different clients from
> > the
> > > > > same
> > > > > > domain. I understand that in future I will have another clients
> > from
> > > > same
> > > > > > problem domain which would like to have similar applications,
> just
> > > with
> > > > > > different design. So I take the route of having 1 product line
> and
> > > > > > customization of that product line for each client, depends on
> > their
> > > > > needs.
> > > > > > This is client facing application, so I would like to cover as
> much
> > > > > mobile
> > > > > > platforms as possible with minimum amount of efforts. Currently I
> > > > support
> > > > > > only Android and iOS platforms, but envision that my clients will
> > > > expand
> > > > > to
> > > > > > the Windows Phone soon, and maybe I will force them to support
> > Tizen
> > > in
> > > > > > next year if that platform would be world-wide popular.
> > > > > > I position my self as
> > > > > > a) heavy Cordova user
> > > > > > b) middle/low platform specific development. (I have to go deep
> in
> > > each
> > > > > > platform, but that's not priority for me as Cordova users)
> > > > > > I maintain 3 Git branches. 1 branch for core product and 2
> branches
> > > for
> > > > > > each client. In each branch I keep, platform specific code for
> the
> > > > > > application (cordova-platform-ios/android code), Cordova plugins
> > > code +
> > > > > > plugins developed specifically to this application.
> > > > > > I definitely sure that I will need to add some functionality to
> the
> > > > core
> > > > > > platforms, either iOS or Android which will benefit the my
> > > > application. I
> > > > > > would try to push to the core Cordova as much as I can, but
> > possible
> > > > that
> > > > > > not all contribution would be useful for the Cordova. Either way
> I
> > > plan
> > > > > for
> > > > > > update to next version of Cordova (3.4, or 3.5 whenether). To
> keep
> > my
> > > > > > changes, which I add to current version of Cordova (3.3) and make
> > > > update
> > > > > to
> > > > > > 3.4 and later easier I keep all code in the source control to
> make
> > > all
> > > > my
> > > > > > future merges easier. Same rules apply to the plugins,maybe I add
> > > some
> > > > > > code/fixes to plugins, or not don't matter - I have to plan for
> > that.
> > > > > > I would like to contribute to Cordova everything what will
> benefit
> > > the
> > > > > > community to meet my selfish goals:
> > > > > > I want to make my upgrade path as straightforward as possible,
> for
> > > > > platform
> > > > > > code and for plugins code.
> > > > > >
> > > > > > Maybe I was too verbose, but that was just to explain that I plan
> > to
> > > > > align
> > > > > > my long-term goals with Cordova's long-term goals. I try to gave
> > more
> > > > > > explanation, so you guys could plan not only for people which
> > create
> > > > > > projects which are working on the specific version of Cordova,
> but
> > > also
> > > > > for
> > > > > > the guys which want to nurture their product together with
> Cordova.
> > > > > >
> > > > > > I plainly don't see:
> > > > > > a) how I could work on my product not keeping ./platforms and
> > > ./plugins
> > > > > > directories in the source control, and
> > > > > > b) why I should don't use Cordova CLI to update contents of my
> > > > > ./platforms
> > > > > > and ./plugins folders. I think that these tool has a good fit for
> > > basic
> > > > > > housekeeping of the files/plugins. Don't want to manually fiddle
> > with
> > > > > > content of plugins for each platform and use plugman/cordova
> > > > executables
> > > > > to
> > > > > > do the job.
> > > > > >
> > > > > > Hopefully I was enough verbose to explain why I have needs what I
> > > have
> > > > > now,
> > > > > > and not too verbose so you flood in details.
> > > > > >
> > > > > > To summarize my input is:
> > > > > > 1. Keep tools that way, that it could work either when ./plugins,
> > > > > > ./platforms in source control, or when these folders not in the
> > VCS.
> > > > > > 2. Take into account that people may want to customize Cordova
> > > > > distribution
> > > > > > and have path to future upgrades.
> > > > > > 3. I want to take responsibility for some burden which this way
> > could
> > > > > > potentially create for you guys,
> > > > > >
> > > > > > Andrey Kurdyumov.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > > > > >
> > > > > > > I've wanted to add Cordova plugin dependencies to the app's
> > > top-level
> > > > > > > config.xml for a long time, but it's never reached the top of
> my
> > > > > > > priorities. I think with that support, we can avoid checking in
> > > > > > ./plugins/
> > > > > > > and ./platforms altogether for 99% of app developers. If it
> > doesn't
> > > > > solve
> > > > > > > anyone's use case, I'd love to hear about it.
> > > > > > >
> > > > > > > Braden
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <
> > rgerbasi@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > CB-4624 is exactly what I am looking for. I am not sure if it
> > > > should
> > > > > be
> > > > > > > > config.xml or some other config file, it probably doesn't
> > matter
> > > > much
> > > > > > > when
> > > > > > > > it comes down to it. Is there any rules currently in place,
> > like
> > > > CLI
> > > > > > > > doesn't touch config.xml?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > > > > agrieve@chromium.org
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is
> the
> > > > > > relevant
> > > > > > > > > issue
> > > > > > > > > here. Please add comments to it if it's not spec'ed or good
> > > > enough.
> > > > > > > > >
> > > > > > > > > Also related is
> > https://issues.apache.org/jira/browse/CB-5006-
> > > > > > meant
> > > > > > > to
> > > > > > > > > address local repos of plugins.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > > > > kant2002@googlemail.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > Would be very helpful if you change formatting of the
> > plugins
> > > > > > > manifest
> > > > > > > > > > files (android.json, ios.json). Currently it is print all
> > > JSON
> > > > > > string
> > > > > > > > to
> > > > > > > > > > the big single line, which difficult to merge when
> needed.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Andrew Grieve <ag...@chromium.org>]

Definitely a config.xml thing.

I don't think anyone's fiddling. If you want to take it on, that'd be
awesome. Mark the issue as assigned to yourself (just gave you JIRA perms)
and have at it! :)

Idea for implementing this:
1. Get "cordova plugin add" at add a <dependency> tag to config.xml
2. Add a "cordova plugin sync" command that adds/removes plugins based on
what's in config.xml



On Tue, Jan 7, 2014 at 9:12 AM, Ross Gerbasi <rg...@gmail.com> wrote:

> Sooooo I think we are all cool on this. Adding this feature does not stop
> anyone from checking in those folders if they desire.
>
> How can I help make this happen? Or is someone already fiddling with this?
> Last activity on the issue was a month ago (
> https://issues.apache.org/jira/browse/CB-4624)
>
> Then again does this still require some choices to be made? I know there is
> a lot of talk of config.xml and cordova.json and what goes where but I am
> assuming this is a config.xml thing.
>
>
> On Tue, Jan 7, 2014 at 11:03 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > I think we're talking somewhat at cross purposes.
> >
> > One of my goals with the CLI is to make the ./platforms and ./plugins
> > directories build artifacts, meaning that you could delete them (or check
> > out a new copy of your project that does not include them) and restore
> them
> > fully with a couple of commands.
> >
> > Currently the two commands would have to be: cordova platform add <all
> your
> > platforms> and cordova plugin add <all your plugins>. The latter is
> > unfortunately long, and we hope to fix that by allowing you to specify
> > required plugins for the project in the top-level app config.xml file, so
> > that the second command becomes simply "cordova plugin add" or "cordova
> > plugin add --deps" or whatever we decide it should be.
> >
> > Why I say we're talking at cross purposes is that there's nothing about
> any
> > of this that stops people from checking some or all of the ./platforms
> > directory into their source control. They'll have to spend some effort
> > maintaining it, as Cordova updates various files, but that's the case if
> > you have custom edits to the native code whether you put it in version
> > control or not.
> >
> > I mention the 99% of Cordova users because at some point it becomes
> > impractical to support 100% with the tool. There's always going to be
> some
> > esoteric use cases that will require some hand-holding to work with the
> > CLI.
> >
> > We have tried to extract most of the things that used to require tweaks
> to
> > the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into
> preferences
> > that can be set from config files. If there are tweaks that are needed by
> > more than a few users and are not covered by preferences, then they
> should
> > be added as new preferences.
> >
> > Braden
> >
> >
> > On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <kant2002@googlemail.com
> > >wrote:
> >
> > > Dan, Ross.
> > >
> > > I complexly agree with both of you. My workflow - my problems. I wrote
> > > about it just so you have background about needs of developers like me.
> > > When I read about number 99% CLI developers, I understand that I am
> from
> > > the not mentioned 1%. And tone of the discussion for me sounds like
> that
> > 1%
> > > would not be taken into consideration.
> > >
> > > Right now I have 2 small issues which would be important for you only
> if
> > > you keep you ./plugins, ./platforms source code in VCS. Don't think
> that
> > > they are valuable enough for you when you main use-case is keep
> ./plugins
> > > and ./platforms outside of VCS, so I better implement them myself and
> > > contribute back to the Cordova.
> > >
> > > What is not clear to me, are such contributions would be welcome or
> not,
> > > since it is for only 1% of people?
> > >
> > > Andrey K.
> > >
> > >
> > >
> > > 2014/1/7 Ross Gerbasi <rg...@gmail.com>
> > >
> > > > Hey Andrey,
> > > >
> > > > Much like you said 99% of the users will want to ignore platforms and
> > > > plugins from version control. Making this work properly would not
> stop
> > > > someone from including them if they wanted to. If your workflow is
> > better
> > > > including those folders you would have no problem doing so.
> > > >
> > > > Ideally though if you can keep your custom code off in plugins, even
> if
> > > > they are not public plugins, would be ideal. Also as Dan mentioned
> you
> > > can
> > > > look into hooks to help modify platforms as needed.
> > > >
> > > > Again though if you find checking everything in easier thats cool but
> > the
> > > > CLI should be setup in a way that we do not need to.
> > > >
> > > >
> > > >
> > > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com>
> wrote:
> > > >
> > > > > Hi Andrey,
> > > > >
> > > > > I have worked on two small, simple Cordova applications, but we
> still
> > > at
> > > > > times had to modify platform specific code.  Not much, but some
> > > > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > > > Android--this
> > > > > is a 2.9.x project for now).
> > > > >
> > > > > Here's my solutions to your issues.
> > > > > * if you need to modify native plugin code, you should fork the
> repo
> > > and
> > > > > manage your changes via a git project, not in your project.
> > > > >
> > > > > If you use a recent enough version of Cordova, you can even pull
> > > plugins
> > > > > off git branches ( see
> https://issues.apache.org/jira/browse/CB-4981)
> > > > so
> > > > > you could have different versions of your apps for different
> clients
> > > pull
> > > > > different branches of the same plugin.
> > > > >
> > > > > * if you need to modify code under platforms, use an
> > after_platform_add
> > > > > hook, and keep your customized platform files elsewhere in your
> > project
> > > > > tree.
> > > > >
> > > > > This way, you aren't version controlling everything, just what
> you've
> > > had
> > > > > to change.  Of course, when the Cordova platform changes underneath
> > you
> > > > > (perhaps a new method is added to AppDelegate.m, and the version
> you
> > > have
> > > > > in source control overwrites that), you need to check these files
> > > > > carefully.  But when you version control everything and you
> upgrade,
> > > you
> > > > > have to merge in your custom changes into the new Cordova code in
> the
> > > > same
> > > > > careful manner, plus you are carrying around everything else under
> > > > > platforms.
> > > > >
> > > > > Of course, I'm a big believer in the CLI, having everyone use the
> > > entire
> > > > > CLI toolchain, and treating everything under platforms and plugins
> as
> > > > > derived code that you can replace at any time.  If this isn't how
> you
> > > > > develop (if you prefer the 'native project dev' workflow, for
> > example),
> > > > > then this may not work for you.
> > > > >
> > > > > Thanks.
> > > > > Dan
> > > > >
> > > > > PS Can you explain how keeping all the code in source control makes
> > > your
> > > > > merges as you move from Cordova version to Cordova version easier?
> >  To
> > > > me,
> > > > > that would seem to make them more difficult.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > > > kant2002@googlemail.com> wrote:
> > > > >
> > > > > About plugin and platform version control.
> > > > > I heard a lot about that, and confused why you think that everybody
> > > would
> > > > > like to remove ./plugins and ./platforms folders from source
> > control. I
> > > > do
> > > > > agree that this is most likely the case for the simple applications
> > and
> > > > for
> > > > > the maybe 99% of current Cordova users, but I don't believe that
> this
> > > is
> > > > > truly important for the Cordova as the ecosystem for the
> > cross-platform
> > > > of
> > > > > the mobile development.
> > > > >
> > > > > Let me explain why I think that keep ./platforms and ./plugins
> under
> > > > source
> > > > > control very important. I would base my reasoning on my current
> > project
> > > > > needs.
> > > > > I currently develop 2 similar products for different clients from
> the
> > > > same
> > > > > domain. I understand that in future I will have another clients
> from
> > > same
> > > > > problem domain which would like to have similar applications, just
> > with
> > > > > different design. So I take the route of having 1 product line and
> > > > > customization of that product line for each client, depends on
> their
> > > > needs.
> > > > > This is client facing application, so I would like to cover as much
> > > > mobile
> > > > > platforms as possible with minimum amount of efforts. Currently I
> > > support
> > > > > only Android and iOS platforms, but envision that my clients will
> > > expand
> > > > to
> > > > > the Windows Phone soon, and maybe I will force them to support
> Tizen
> > in
> > > > > next year if that platform would be world-wide popular.
> > > > > I position my self as
> > > > > a) heavy Cordova user
> > > > > b) middle/low platform specific development. (I have to go deep in
> > each
> > > > > platform, but that's not priority for me as Cordova users)
> > > > > I maintain 3 Git branches. 1 branch for core product and 2 branches
> > for
> > > > > each client. In each branch I keep, platform specific code for the
> > > > > application (cordova-platform-ios/android code), Cordova plugins
> > code +
> > > > > plugins developed specifically to this application.
> > > > > I definitely sure that I will need to add some functionality to the
> > > core
> > > > > platforms, either iOS or Android which will benefit the my
> > > application. I
> > > > > would try to push to the core Cordova as much as I can, but
> possible
> > > that
> > > > > not all contribution would be useful for the Cordova. Either way I
> > plan
> > > > for
> > > > > update to next version of Cordova (3.4, or 3.5 whenether). To keep
> my
> > > > > changes, which I add to current version of Cordova (3.3) and make
> > > update
> > > > to
> > > > > 3.4 and later easier I keep all code in the source control to make
> > all
> > > my
> > > > > future merges easier. Same rules apply to the plugins,maybe I add
> > some
> > > > > code/fixes to plugins, or not don't matter - I have to plan for
> that.
> > > > > I would like to contribute to Cordova everything what will benefit
> > the
> > > > > community to meet my selfish goals:
> > > > > I want to make my upgrade path as straightforward as possible, for
> > > > platform
> > > > > code and for plugins code.
> > > > >
> > > > > Maybe I was too verbose, but that was just to explain that I plan
> to
> > > > align
> > > > > my long-term goals with Cordova's long-term goals. I try to gave
> more
> > > > > explanation, so you guys could plan not only for people which
> create
> > > > > projects which are working on the specific version of Cordova, but
> > also
> > > > for
> > > > > the guys which want to nurture their product together with Cordova.
> > > > >
> > > > > I plainly don't see:
> > > > > a) how I could work on my product not keeping ./platforms and
> > ./plugins
> > > > > directories in the source control, and
> > > > > b) why I should don't use Cordova CLI to update contents of my
> > > > ./platforms
> > > > > and ./plugins folders. I think that these tool has a good fit for
> > basic
> > > > > housekeeping of the files/plugins. Don't want to manually fiddle
> with
> > > > > content of plugins for each platform and use plugman/cordova
> > > executables
> > > > to
> > > > > do the job.
> > > > >
> > > > > Hopefully I was enough verbose to explain why I have needs what I
> > have
> > > > now,
> > > > > and not too verbose so you flood in details.
> > > > >
> > > > > To summarize my input is:
> > > > > 1. Keep tools that way, that it could work either when ./plugins,
> > > > > ./platforms in source control, or when these folders not in the
> VCS.
> > > > > 2. Take into account that people may want to customize Cordova
> > > > distribution
> > > > > and have path to future upgrades.
> > > > > 3. I want to take responsibility for some burden which this way
> could
> > > > > potentially create for you guys,
> > > > >
> > > > > Andrey Kurdyumov.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > > > >
> > > > > > I've wanted to add Cordova plugin dependencies to the app's
> > top-level
> > > > > > config.xml for a long time, but it's never reached the top of my
> > > > > > priorities. I think with that support, we can avoid checking in
> > > > > ./plugins/
> > > > > > and ./platforms altogether for 99% of app developers. If it
> doesn't
> > > > solve
> > > > > > anyone's use case, I'd love to hear about it.
> > > > > >
> > > > > > Braden
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <
> rgerbasi@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > CB-4624 is exactly what I am looking for. I am not sure if it
> > > should
> > > > be
> > > > > > > config.xml or some other config file, it probably doesn't
> matter
> > > much
> > > > > > when
> > > > > > > it comes down to it. Is there any rules currently in place,
> like
> > > CLI
> > > > > > > doesn't touch config.xml?
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > > > agrieve@chromium.org
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> > > > > relevant
> > > > > > > > issue
> > > > > > > > here. Please add comments to it if it's not spec'ed or good
> > > enough.
> > > > > > > >
> > > > > > > > Also related is
> https://issues.apache.org/jira/browse/CB-5006-
> > > > > meant
> > > > > > to
> > > > > > > > address local repos of plugins.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > > > kant2002@googlemail.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > Would be very helpful if you change formatting of the
> plugins
> > > > > > manifest
> > > > > > > > > files (android.json, ios.json). Currently it is print all
> > JSON
> > > > > string
> > > > > > > to
> > > > > > > > > the big single line, which difficult to merge when needed.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Ross Gerbasi <rg...@gmail.com>]

Sooooo I think we are all cool on this. Adding this feature does not stop
anyone from checking in those folders if they desire.

How can I help make this happen? Or is someone already fiddling with this?
Last activity on the issue was a month ago (
https://issues.apache.org/jira/browse/CB-4624)

Then again does this still require some choices to be made? I know there is
a lot of talk of config.xml and cordova.json and what goes where but I am
assuming this is a config.xml thing.


On Tue, Jan 7, 2014 at 11:03 AM, Braden Shepherdson <br...@chromium.org>wrote:

> I think we're talking somewhat at cross purposes.
>
> One of my goals with the CLI is to make the ./platforms and ./plugins
> directories build artifacts, meaning that you could delete them (or check
> out a new copy of your project that does not include them) and restore them
> fully with a couple of commands.
>
> Currently the two commands would have to be: cordova platform add <all your
> platforms> and cordova plugin add <all your plugins>. The latter is
> unfortunately long, and we hope to fix that by allowing you to specify
> required plugins for the project in the top-level app config.xml file, so
> that the second command becomes simply "cordova plugin add" or "cordova
> plugin add --deps" or whatever we decide it should be.
>
> Why I say we're talking at cross purposes is that there's nothing about any
> of this that stops people from checking some or all of the ./platforms
> directory into their source control. They'll have to spend some effort
> maintaining it, as Cordova updates various files, but that's the case if
> you have custom edits to the native code whether you put it in version
> control or not.
>
> I mention the 99% of Cordova users because at some point it becomes
> impractical to support 100% with the tool. There's always going to be some
> esoteric use cases that will require some hand-holding to work with the
> CLI.
>
> We have tried to extract most of the things that used to require tweaks to
> the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into preferences
> that can be set from config files. If there are tweaks that are needed by
> more than a few users and are not covered by preferences, then they should
> be added as new preferences.
>
> Braden
>
>
> On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <kant2002@googlemail.com
> >wrote:
>
> > Dan, Ross.
> >
> > I complexly agree with both of you. My workflow - my problems. I wrote
> > about it just so you have background about needs of developers like me.
> > When I read about number 99% CLI developers, I understand that I am from
> > the not mentioned 1%. And tone of the discussion for me sounds like that
> 1%
> > would not be taken into consideration.
> >
> > Right now I have 2 small issues which would be important for you only if
> > you keep you ./plugins, ./platforms source code in VCS. Don't think that
> > they are valuable enough for you when you main use-case is keep ./plugins
> > and ./platforms outside of VCS, so I better implement them myself and
> > contribute back to the Cordova.
> >
> > What is not clear to me, are such contributions would be welcome or not,
> > since it is for only 1% of people?
> >
> > Andrey K.
> >
> >
> >
> > 2014/1/7 Ross Gerbasi <rg...@gmail.com>
> >
> > > Hey Andrey,
> > >
> > > Much like you said 99% of the users will want to ignore platforms and
> > > plugins from version control. Making this work properly would not stop
> > > someone from including them if they wanted to. If your workflow is
> better
> > > including those folders you would have no problem doing so.
> > >
> > > Ideally though if you can keep your custom code off in plugins, even if
> > > they are not public plugins, would be ideal. Also as Dan mentioned you
> > can
> > > look into hooks to help modify platforms as needed.
> > >
> > > Again though if you find checking everything in easier thats cool but
> the
> > > CLI should be setup in a way that we do not need to.
> > >
> > >
> > >
> > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com> wrote:
> > >
> > > > Hi Andrey,
> > > >
> > > > I have worked on two small, simple Cordova applications, but we still
> > at
> > > > times had to modify platform specific code.  Not much, but some
> > > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > > Android--this
> > > > is a 2.9.x project for now).
> > > >
> > > > Here's my solutions to your issues.
> > > > * if you need to modify native plugin code, you should fork the repo
> > and
> > > > manage your changes via a git project, not in your project.
> > > >
> > > > If you use a recent enough version of Cordova, you can even pull
> > plugins
> > > > off git branches ( see https://issues.apache.org/jira/browse/CB-4981)
> > > so
> > > > you could have different versions of your apps for different clients
> > pull
> > > > different branches of the same plugin.
> > > >
> > > > * if you need to modify code under platforms, use an
> after_platform_add
> > > > hook, and keep your customized platform files elsewhere in your
> project
> > > > tree.
> > > >
> > > > This way, you aren't version controlling everything, just what you've
> > had
> > > > to change.  Of course, when the Cordova platform changes underneath
> you
> > > > (perhaps a new method is added to AppDelegate.m, and the version you
> > have
> > > > in source control overwrites that), you need to check these files
> > > > carefully.  But when you version control everything and you upgrade,
> > you
> > > > have to merge in your custom changes into the new Cordova code in the
> > > same
> > > > careful manner, plus you are carrying around everything else under
> > > > platforms.
> > > >
> > > > Of course, I'm a big believer in the CLI, having everyone use the
> > entire
> > > > CLI toolchain, and treating everything under platforms and plugins as
> > > > derived code that you can replace at any time.  If this isn't how you
> > > > develop (if you prefer the 'native project dev' workflow, for
> example),
> > > > then this may not work for you.
> > > >
> > > > Thanks.
> > > > Dan
> > > >
> > > > PS Can you explain how keeping all the code in source control makes
> > your
> > > > merges as you move from Cordova version to Cordova version easier?
>  To
> > > me,
> > > > that would seem to make them more difficult.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > > kant2002@googlemail.com> wrote:
> > > >
> > > > About plugin and platform version control.
> > > > I heard a lot about that, and confused why you think that everybody
> > would
> > > > like to remove ./plugins and ./platforms folders from source
> control. I
> > > do
> > > > agree that this is most likely the case for the simple applications
> and
> > > for
> > > > the maybe 99% of current Cordova users, but I don't believe that this
> > is
> > > > truly important for the Cordova as the ecosystem for the
> cross-platform
> > > of
> > > > the mobile development.
> > > >
> > > > Let me explain why I think that keep ./platforms and ./plugins under
> > > source
> > > > control very important. I would base my reasoning on my current
> project
> > > > needs.
> > > > I currently develop 2 similar products for different clients from the
> > > same
> > > > domain. I understand that in future I will have another clients from
> > same
> > > > problem domain which would like to have similar applications, just
> with
> > > > different design. So I take the route of having 1 product line and
> > > > customization of that product line for each client, depends on their
> > > needs.
> > > > This is client facing application, so I would like to cover as much
> > > mobile
> > > > platforms as possible with minimum amount of efforts. Currently I
> > support
> > > > only Android and iOS platforms, but envision that my clients will
> > expand
> > > to
> > > > the Windows Phone soon, and maybe I will force them to support Tizen
> in
> > > > next year if that platform would be world-wide popular.
> > > > I position my self as
> > > > a) heavy Cordova user
> > > > b) middle/low platform specific development. (I have to go deep in
> each
> > > > platform, but that's not priority for me as Cordova users)
> > > > I maintain 3 Git branches. 1 branch for core product and 2 branches
> for
> > > > each client. In each branch I keep, platform specific code for the
> > > > application (cordova-platform-ios/android code), Cordova plugins
> code +
> > > > plugins developed specifically to this application.
> > > > I definitely sure that I will need to add some functionality to the
> > core
> > > > platforms, either iOS or Android which will benefit the my
> > application. I
> > > > would try to push to the core Cordova as much as I can, but possible
> > that
> > > > not all contribution would be useful for the Cordova. Either way I
> plan
> > > for
> > > > update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> > > > changes, which I add to current version of Cordova (3.3) and make
> > update
> > > to
> > > > 3.4 and later easier I keep all code in the source control to make
> all
> > my
> > > > future merges easier. Same rules apply to the plugins,maybe I add
> some
> > > > code/fixes to plugins, or not don't matter - I have to plan for that.
> > > > I would like to contribute to Cordova everything what will benefit
> the
> > > > community to meet my selfish goals:
> > > > I want to make my upgrade path as straightforward as possible, for
> > > platform
> > > > code and for plugins code.
> > > >
> > > > Maybe I was too verbose, but that was just to explain that I plan to
> > > align
> > > > my long-term goals with Cordova's long-term goals. I try to gave more
> > > > explanation, so you guys could plan not only for people which create
> > > > projects which are working on the specific version of Cordova, but
> also
> > > for
> > > > the guys which want to nurture their product together with Cordova.
> > > >
> > > > I plainly don't see:
> > > > a) how I could work on my product not keeping ./platforms and
> ./plugins
> > > > directories in the source control, and
> > > > b) why I should don't use Cordova CLI to update contents of my
> > > ./platforms
> > > > and ./plugins folders. I think that these tool has a good fit for
> basic
> > > > housekeeping of the files/plugins. Don't want to manually fiddle with
> > > > content of plugins for each platform and use plugman/cordova
> > executables
> > > to
> > > > do the job.
> > > >
> > > > Hopefully I was enough verbose to explain why I have needs what I
> have
> > > now,
> > > > and not too verbose so you flood in details.
> > > >
> > > > To summarize my input is:
> > > > 1. Keep tools that way, that it could work either when ./plugins,
> > > > ./platforms in source control, or when these folders not in the VCS.
> > > > 2. Take into account that people may want to customize Cordova
> > > distribution
> > > > and have path to future upgrades.
> > > > 3. I want to take responsibility for some burden which this way could
> > > > potentially create for you guys,
> > > >
> > > > Andrey Kurdyumov.
> > > >
> > > >
> > > >
> > > >
> > > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > > >
> > > > > I've wanted to add Cordova plugin dependencies to the app's
> top-level
> > > > > config.xml for a long time, but it's never reached the top of my
> > > > > priorities. I think with that support, we can avoid checking in
> > > > ./plugins/
> > > > > and ./platforms altogether for 99% of app developers. If it doesn't
> > > solve
> > > > > anyone's use case, I'd love to hear about it.
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > CB-4624 is exactly what I am looking for. I am not sure if it
> > should
> > > be
> > > > > > config.xml or some other config file, it probably doesn't matter
> > much
> > > > > when
> > > > > > it comes down to it. Is there any rules currently in place, like
> > CLI
> > > > > > doesn't touch config.xml?
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > > > >wrote:
> > > > > >
> > > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> > > > relevant
> > > > > > > issue
> > > > > > > here. Please add comments to it if it's not spec'ed or good
> > enough.
> > > > > > >
> > > > > > > Also related is https://issues.apache.org/jira/browse/CB-5006-
> > > > meant
> > > > > to
> > > > > > > address local repos of plugins.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > > kant2002@googlemail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > Would be very helpful if you change formatting of the plugins
> > > > > manifest
> > > > > > > > files (android.json, ios.json). Currently it is print all
> JSON
> > > > string
> > > > > > to
> > > > > > > > the big single line, which difficult to merge when needed.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Andrey Kurdumov <ka...@googlemail.com>]

Thanks, for all your patients guys.

@Braden
Yes, somewhat this is cross purpose.  I built my developer workflow around
Cordova CLI tools, and since I keep stuff in the VCS, some minor stuff
annoys me. Right now, I just have no time to look in the Cordova CLI and
made a fix for that. When I free myself for some learning, I will comeback
with fixes and reasoning for them.

@Brian
I'm independent developer. Would like to contribute to Cordova iOS and
Cordova Android if that would benefit my current projects. I could take
responsibility for my additions and support them as long as I will stay in
the mobile space (couple next years at least).

@all
+1 for simple 'plugman install' syntax.


2014/1/7 Braden Shepherdson <br...@chromium.org>

> I think we're talking somewhat at cross purposes.
>
> One of my goals with the CLI is to make the ./platforms and ./plugins
> directories build artifacts, meaning that you could delete them (or check
> out a new copy of your project that does not include them) and restore them
> fully with a couple of commands.
>
> Currently the two commands would have to be: cordova platform add <all your
> platforms> and cordova plugin add <all your plugins>. The latter is
> unfortunately long, and we hope to fix that by allowing you to specify
> required plugins for the project in the top-level app config.xml file, so
> that the second command becomes simply "cordova plugin add" or "cordova
> plugin add --deps" or whatever we decide it should be.
>
> Why I say we're talking at cross purposes is that there's nothing about any
> of this that stops people from checking some or all of the ./platforms
> directory into their source control. They'll have to spend some effort
> maintaining it, as Cordova updates various files, but that's the case if
> you have custom edits to the native code whether you put it in version
> control or not.
>
> I mention the 99% of Cordova users because at some point it becomes
> impractical to support 100% with the tool. There's always going to be some
> esoteric use cases that will require some hand-holding to work with the
> CLI.
>
> We have tried to extract most of the things that used to require tweaks to
> the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into preferences
> that can be set from config files. If there are tweaks that are needed by
> more than a few users and are not covered by preferences, then they should
> be added as new preferences.
>
> Braden
>
>
> On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <kant2002@googlemail.com
> >wrote:
>
> > Dan, Ross.
> >
> > I complexly agree with both of you. My workflow - my problems. I wrote
> > about it just so you have background about needs of developers like me.
> > When I read about number 99% CLI developers, I understand that I am from
> > the not mentioned 1%. And tone of the discussion for me sounds like that
> 1%
> > would not be taken into consideration.
> >
> > Right now I have 2 small issues which would be important for you only if
> > you keep you ./plugins, ./platforms source code in VCS. Don't think that
> > they are valuable enough for you when you main use-case is keep ./plugins
> > and ./platforms outside of VCS, so I better implement them myself and
> > contribute back to the Cordova.
> >
> > What is not clear to me, are such contributions would be welcome or not,
> > since it is for only 1% of people?
> >
> > Andrey K.
> >
> >
> >
> > 2014/1/7 Ross Gerbasi <rg...@gmail.com>
> >
> > > Hey Andrey,
> > >
> > > Much like you said 99% of the users will want to ignore platforms and
> > > plugins from version control. Making this work properly would not stop
> > > someone from including them if they wanted to. If your workflow is
> better
> > > including those folders you would have no problem doing so.
> > >
> > > Ideally though if you can keep your custom code off in plugins, even if
> > > they are not public plugins, would be ideal. Also as Dan mentioned you
> > can
> > > look into hooks to help modify platforms as needed.
> > >
> > > Again though if you find checking everything in easier thats cool but
> the
> > > CLI should be setup in a way that we do not need to.
> > >
> > >
> > >
> > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com> wrote:
> > >
> > > > Hi Andrey,
> > > >
> > > > I have worked on two small, simple Cordova applications, but we still
> > at
> > > > times had to modify platform specific code.  Not much, but some
> > > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > > Android--this
> > > > is a 2.9.x project for now).
> > > >
> > > > Here's my solutions to your issues.
> > > > * if you need to modify native plugin code, you should fork the repo
> > and
> > > > manage your changes via a git project, not in your project.
> > > >
> > > > If you use a recent enough version of Cordova, you can even pull
> > plugins
> > > > off git branches ( see https://issues.apache.org/jira/browse/CB-4981)
> > > so
> > > > you could have different versions of your apps for different clients
> > pull
> > > > different branches of the same plugin.
> > > >
> > > > * if you need to modify code under platforms, use an
> after_platform_add
> > > > hook, and keep your customized platform files elsewhere in your
> project
> > > > tree.
> > > >
> > > > This way, you aren't version controlling everything, just what you've
> > had
> > > > to change.  Of course, when the Cordova platform changes underneath
> you
> > > > (perhaps a new method is added to AppDelegate.m, and the version you
> > have
> > > > in source control overwrites that), you need to check these files
> > > > carefully.  But when you version control everything and you upgrade,
> > you
> > > > have to merge in your custom changes into the new Cordova code in the
> > > same
> > > > careful manner, plus you are carrying around everything else under
> > > > platforms.
> > > >
> > > > Of course, I'm a big believer in the CLI, having everyone use the
> > entire
> > > > CLI toolchain, and treating everything under platforms and plugins as
> > > > derived code that you can replace at any time.  If this isn't how you
> > > > develop (if you prefer the 'native project dev' workflow, for
> example),
> > > > then this may not work for you.
> > > >
> > > > Thanks.
> > > > Dan
> > > >
> > > > PS Can you explain how keeping all the code in source control makes
> > your
> > > > merges as you move from Cordova version to Cordova version easier?
>  To
> > > me,
> > > > that would seem to make them more difficult.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > > kant2002@googlemail.com> wrote:
> > > >
> > > > About plugin and platform version control.
> > > > I heard a lot about that, and confused why you think that everybody
> > would
> > > > like to remove ./plugins and ./platforms folders from source
> control. I
> > > do
> > > > agree that this is most likely the case for the simple applications
> and
> > > for
> > > > the maybe 99% of current Cordova users, but I don't believe that this
> > is
> > > > truly important for the Cordova as the ecosystem for the
> cross-platform
> > > of
> > > > the mobile development.
> > > >
> > > > Let me explain why I think that keep ./platforms and ./plugins under
> > > source
> > > > control very important. I would base my reasoning on my current
> project
> > > > needs.
> > > > I currently develop 2 similar products for different clients from the
> > > same
> > > > domain. I understand that in future I will have another clients from
> > same
> > > > problem domain which would like to have similar applications, just
> with
> > > > different design. So I take the route of having 1 product line and
> > > > customization of that product line for each client, depends on their
> > > needs.
> > > > This is client facing application, so I would like to cover as much
> > > mobile
> > > > platforms as possible with minimum amount of efforts. Currently I
> > support
> > > > only Android and iOS platforms, but envision that my clients will
> > expand
> > > to
> > > > the Windows Phone soon, and maybe I will force them to support Tizen
> in
> > > > next year if that platform would be world-wide popular.
> > > > I position my self as
> > > > a) heavy Cordova user
> > > > b) middle/low platform specific development. (I have to go deep in
> each
> > > > platform, but that's not priority for me as Cordova users)
> > > > I maintain 3 Git branches. 1 branch for core product and 2 branches
> for
> > > > each client. In each branch I keep, platform specific code for the
> > > > application (cordova-platform-ios/android code), Cordova plugins
> code +
> > > > plugins developed specifically to this application.
> > > > I definitely sure that I will need to add some functionality to the
> > core
> > > > platforms, either iOS or Android which will benefit the my
> > application. I
> > > > would try to push to the core Cordova as much as I can, but possible
> > that
> > > > not all contribution would be useful for the Cordova. Either way I
> plan
> > > for
> > > > update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> > > > changes, which I add to current version of Cordova (3.3) and make
> > update
> > > to
> > > > 3.4 and later easier I keep all code in the source control to make
> all
> > my
> > > > future merges easier. Same rules apply to the plugins,maybe I add
> some
> > > > code/fixes to plugins, or not don't matter - I have to plan for that.
> > > > I would like to contribute to Cordova everything what will benefit
> the
> > > > community to meet my selfish goals:
> > > > I want to make my upgrade path as straightforward as possible, for
> > > platform
> > > > code and for plugins code.
> > > >
> > > > Maybe I was too verbose, but that was just to explain that I plan to
> > > align
> > > > my long-term goals with Cordova's long-term goals. I try to gave more
> > > > explanation, so you guys could plan not only for people which create
> > > > projects which are working on the specific version of Cordova, but
> also
> > > for
> > > > the guys which want to nurture their product together with Cordova.
> > > >
> > > > I plainly don't see:
> > > > a) how I could work on my product not keeping ./platforms and
> ./plugins
> > > > directories in the source control, and
> > > > b) why I should don't use Cordova CLI to update contents of my
> > > ./platforms
> > > > and ./plugins folders. I think that these tool has a good fit for
> basic
> > > > housekeeping of the files/plugins. Don't want to manually fiddle with
> > > > content of plugins for each platform and use plugman/cordova
> > executables
> > > to
> > > > do the job.
> > > >
> > > > Hopefully I was enough verbose to explain why I have needs what I
> have
> > > now,
> > > > and not too verbose so you flood in details.
> > > >
> > > > To summarize my input is:
> > > > 1. Keep tools that way, that it could work either when ./plugins,
> > > > ./platforms in source control, or when these folders not in the VCS.
> > > > 2. Take into account that people may want to customize Cordova
> > > distribution
> > > > and have path to future upgrades.
> > > > 3. I want to take responsibility for some burden which this way could
> > > > potentially create for you guys,
> > > >
> > > > Andrey Kurdyumov.
> > > >
> > > >
> > > >
> > > >
> > > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > > >
> > > > > I've wanted to add Cordova plugin dependencies to the app's
> top-level
> > > > > config.xml for a long time, but it's never reached the top of my
> > > > > priorities. I think with that support, we can avoid checking in
> > > > ./plugins/
> > > > > and ./platforms altogether for 99% of app developers. If it doesn't
> > > solve
> > > > > anyone's use case, I'd love to hear about it.
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > CB-4624 is exactly what I am looking for. I am not sure if it
> > should
> > > be
> > > > > > config.xml or some other config file, it probably doesn't matter
> > much
> > > > > when
> > > > > > it comes down to it. Is there any rules currently in place, like
> > CLI
> > > > > > doesn't touch config.xml?
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > > > >wrote:
> > > > > >
> > > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> > > > relevant
> > > > > > > issue
> > > > > > > here. Please add comments to it if it's not spec'ed or good
> > enough.
> > > > > > >
> > > > > > > Also related is https://issues.apache.org/jira/browse/CB-5006-
> > > > meant
> > > > > to
> > > > > > > address local repos of plugins.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > > kant2002@googlemail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > Would be very helpful if you change formatting of the plugins
> > > > > manifest
> > > > > > > > files (android.json, ios.json). Currently it is print all
> JSON
> > > > string
> > > > > > to
> > > > > > > > the big single line, which difficult to merge when needed.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Braden Shepherdson <br...@chromium.org>]

I think we're talking somewhat at cross purposes.

One of my goals with the CLI is to make the ./platforms and ./plugins
directories build artifacts, meaning that you could delete them (or check
out a new copy of your project that does not include them) and restore them
fully with a couple of commands.

Currently the two commands would have to be: cordova platform add <all your
platforms> and cordova plugin add <all your plugins>. The latter is
unfortunately long, and we hope to fix that by allowing you to specify
required plugins for the project in the top-level app config.xml file, so
that the second command becomes simply "cordova plugin add" or "cordova
plugin add --deps" or whatever we decide it should be.

Why I say we're talking at cross purposes is that there's nothing about any
of this that stops people from checking some or all of the ./platforms
directory into their source control. They'll have to spend some effort
maintaining it, as Cordova updates various files, but that's the case if
you have custom edits to the native code whether you put it in version
control or not.

I mention the 99% of Cordova users because at some point it becomes
impractical to support 100% with the tool. There's always going to be some
esoteric use cases that will require some hand-holding to work with the CLI.

We have tried to extract most of the things that used to require tweaks to
the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into preferences
that can be set from config files. If there are tweaks that are needed by
more than a few users and are not covered by preferences, then they should
be added as new preferences.

Braden


On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov <ka...@googlemail.com>wrote:

> Dan, Ross.
>
> I complexly agree with both of you. My workflow - my problems. I wrote
> about it just so you have background about needs of developers like me.
> When I read about number 99% CLI developers, I understand that I am from
> the not mentioned 1%. And tone of the discussion for me sounds like that 1%
> would not be taken into consideration.
>
> Right now I have 2 small issues which would be important for you only if
> you keep you ./plugins, ./platforms source code in VCS. Don't think that
> they are valuable enough for you when you main use-case is keep ./plugins
> and ./platforms outside of VCS, so I better implement them myself and
> contribute back to the Cordova.
>
> What is not clear to me, are such contributions would be welcome or not,
> since it is for only 1% of people?
>
> Andrey K.
>
>
>
> 2014/1/7 Ross Gerbasi <rg...@gmail.com>
>
> > Hey Andrey,
> >
> > Much like you said 99% of the users will want to ignore platforms and
> > plugins from version control. Making this work properly would not stop
> > someone from including them if they wanted to. If your workflow is better
> > including those folders you would have no problem doing so.
> >
> > Ideally though if you can keep your custom code off in plugins, even if
> > they are not public plugins, would be ideal. Also as Dan mentioned you
> can
> > look into hooks to help modify platforms as needed.
> >
> > Again though if you find checking everything in easier thats cool but the
> > CLI should be setup in a way that we do not need to.
> >
> >
> >
> > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com> wrote:
> >
> > > Hi Andrey,
> > >
> > > I have worked on two small, simple Cordova applications, but we still
> at
> > > times had to modify platform specific code.  Not much, but some
> > > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> > Android--this
> > > is a 2.9.x project for now).
> > >
> > > Here's my solutions to your issues.
> > > * if you need to modify native plugin code, you should fork the repo
> and
> > > manage your changes via a git project, not in your project.
> > >
> > > If you use a recent enough version of Cordova, you can even pull
> plugins
> > > off git branches ( see https://issues.apache.org/jira/browse/CB-4981 )
> > so
> > > you could have different versions of your apps for different clients
> pull
> > > different branches of the same plugin.
> > >
> > > * if you need to modify code under platforms, use an after_platform_add
> > > hook, and keep your customized platform files elsewhere in your project
> > > tree.
> > >
> > > This way, you aren't version controlling everything, just what you've
> had
> > > to change.  Of course, when the Cordova platform changes underneath you
> > > (perhaps a new method is added to AppDelegate.m, and the version you
> have
> > > in source control overwrites that), you need to check these files
> > > carefully.  But when you version control everything and you upgrade,
> you
> > > have to merge in your custom changes into the new Cordova code in the
> > same
> > > careful manner, plus you are carrying around everything else under
> > > platforms.
> > >
> > > Of course, I'm a big believer in the CLI, having everyone use the
> entire
> > > CLI toolchain, and treating everything under platforms and plugins as
> > > derived code that you can replace at any time.  If this isn't how you
> > > develop (if you prefer the 'native project dev' workflow, for example),
> > > then this may not work for you.
> > >
> > > Thanks.
> > > Dan
> > >
> > > PS Can you explain how keeping all the code in source control makes
> your
> > > merges as you move from Cordova version to Cordova version easier?  To
> > me,
> > > that would seem to make them more difficult.
> > >
> > >
> > >
> > >
> > >
> > > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > > kant2002@googlemail.com> wrote:
> > >
> > > About plugin and platform version control.
> > > I heard a lot about that, and confused why you think that everybody
> would
> > > like to remove ./plugins and ./platforms folders from source control. I
> > do
> > > agree that this is most likely the case for the simple applications and
> > for
> > > the maybe 99% of current Cordova users, but I don't believe that this
> is
> > > truly important for the Cordova as the ecosystem for the cross-platform
> > of
> > > the mobile development.
> > >
> > > Let me explain why I think that keep ./platforms and ./plugins under
> > source
> > > control very important. I would base my reasoning on my current project
> > > needs.
> > > I currently develop 2 similar products for different clients from the
> > same
> > > domain. I understand that in future I will have another clients from
> same
> > > problem domain which would like to have similar applications, just with
> > > different design. So I take the route of having 1 product line and
> > > customization of that product line for each client, depends on their
> > needs.
> > > This is client facing application, so I would like to cover as much
> > mobile
> > > platforms as possible with minimum amount of efforts. Currently I
> support
> > > only Android and iOS platforms, but envision that my clients will
> expand
> > to
> > > the Windows Phone soon, and maybe I will force them to support Tizen in
> > > next year if that platform would be world-wide popular.
> > > I position my self as
> > > a) heavy Cordova user
> > > b) middle/low platform specific development. (I have to go deep in each
> > > platform, but that's not priority for me as Cordova users)
> > > I maintain 3 Git branches. 1 branch for core product and 2 branches for
> > > each client. In each branch I keep, platform specific code for the
> > > application (cordova-platform-ios/android code), Cordova plugins code +
> > > plugins developed specifically to this application.
> > > I definitely sure that I will need to add some functionality to the
> core
> > > platforms, either iOS or Android which will benefit the my
> application. I
> > > would try to push to the core Cordova as much as I can, but possible
> that
> > > not all contribution would be useful for the Cordova. Either way I plan
> > for
> > > update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> > > changes, which I add to current version of Cordova (3.3) and make
> update
> > to
> > > 3.4 and later easier I keep all code in the source control to make all
> my
> > > future merges easier. Same rules apply to the plugins,maybe I add some
> > > code/fixes to plugins, or not don't matter - I have to plan for that.
> > > I would like to contribute to Cordova everything what will benefit the
> > > community to meet my selfish goals:
> > > I want to make my upgrade path as straightforward as possible, for
> > platform
> > > code and for plugins code.
> > >
> > > Maybe I was too verbose, but that was just to explain that I plan to
> > align
> > > my long-term goals with Cordova's long-term goals. I try to gave more
> > > explanation, so you guys could plan not only for people which create
> > > projects which are working on the specific version of Cordova, but also
> > for
> > > the guys which want to nurture their product together with Cordova.
> > >
> > > I plainly don't see:
> > > a) how I could work on my product not keeping ./platforms and ./plugins
> > > directories in the source control, and
> > > b) why I should don't use Cordova CLI to update contents of my
> > ./platforms
> > > and ./plugins folders. I think that these tool has a good fit for basic
> > > housekeeping of the files/plugins. Don't want to manually fiddle with
> > > content of plugins for each platform and use plugman/cordova
> executables
> > to
> > > do the job.
> > >
> > > Hopefully I was enough verbose to explain why I have needs what I have
> > now,
> > > and not too verbose so you flood in details.
> > >
> > > To summarize my input is:
> > > 1. Keep tools that way, that it could work either when ./plugins,
> > > ./platforms in source control, or when these folders not in the VCS.
> > > 2. Take into account that people may want to customize Cordova
> > distribution
> > > and have path to future upgrades.
> > > 3. I want to take responsibility for some burden which this way could
> > > potentially create for you guys,
> > >
> > > Andrey Kurdyumov.
> > >
> > >
> > >
> > >
> > > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> > >
> > > > I've wanted to add Cordova plugin dependencies to the app's top-level
> > > > config.xml for a long time, but it's never reached the top of my
> > > > priorities. I think with that support, we can avoid checking in
> > > ./plugins/
> > > > and ./platforms altogether for 99% of app developers. If it doesn't
> > solve
> > > > anyone's use case, I'd love to hear about it.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com>
> > > wrote:
> > > >
> > > > > CB-4624 is exactly what I am looking for. I am not sure if it
> should
> > be
> > > > > config.xml or some other config file, it probably doesn't matter
> much
> > > > when
> > > > > it comes down to it. Is there any rules currently in place, like
> CLI
> > > > > doesn't touch config.xml?
> > > > >
> > > > >
> > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> > agrieve@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> > > relevant
> > > > > > issue
> > > > > > here. Please add comments to it if it's not spec'ed or good
> enough.
> > > > > >
> > > > > > Also related is https://issues.apache.org/jira/browse/CB-5006 -
> > > meant
> > > > to
> > > > > > address local repos of plugins.
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > > kant2002@googlemail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Would be very helpful if you change formatting of the plugins
> > > > manifest
> > > > > > > files (android.json, ios.json). Currently it is print all JSON
> > > string
> > > > > to
> > > > > > > the big single line, which difficult to merge when needed.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Andrey Kurdumov <ka...@googlemail.com>]

Dan, Ross.

I complexly agree with both of you. My workflow - my problems. I wrote
about it just so you have background about needs of developers like me.
When I read about number 99% CLI developers, I understand that I am from
the not mentioned 1%. And tone of the discussion for me sounds like that 1%
would not be taken into consideration.

Right now I have 2 small issues which would be important for you only if
you keep you ./plugins, ./platforms source code in VCS. Don't think that
they are valuable enough for you when you main use-case is keep ./plugins
and ./platforms outside of VCS, so I better implement them myself and
contribute back to the Cordova.

What is not clear to me, are such contributions would be welcome or not,
since it is for only 1% of people?

Andrey K.



2014/1/7 Ross Gerbasi <rg...@gmail.com>

> Hey Andrey,
>
> Much like you said 99% of the users will want to ignore platforms and
> plugins from version control. Making this work properly would not stop
> someone from including them if they wanted to. If your workflow is better
> including those folders you would have no problem doing so.
>
> Ideally though if you can keep your custom code off in plugins, even if
> they are not public plugins, would be ideal. Also as Dan mentioned you can
> look into hooks to help modify platforms as needed.
>
> Again though if you find checking everything in easier thats cool but the
> CLI should be setup in a way that we do not need to.
>
>
>
> On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com> wrote:
>
> > Hi Andrey,
> >
> > I have worked on two small, simple Cordova applications, but we still at
> > times had to modify platform specific code.  Not much, but some
> > (AppDelegate.m for the iOS app, and the DroidGap subclass for
> Android--this
> > is a 2.9.x project for now).
> >
> > Here's my solutions to your issues.
> > * if you need to modify native plugin code, you should fork the repo and
> > manage your changes via a git project, not in your project.
> >
> > If you use a recent enough version of Cordova, you can even pull plugins
> > off git branches ( see https://issues.apache.org/jira/browse/CB-4981 )
> so
> > you could have different versions of your apps for different clients pull
> > different branches of the same plugin.
> >
> > * if you need to modify code under platforms, use an after_platform_add
> > hook, and keep your customized platform files elsewhere in your project
> > tree.
> >
> > This way, you aren't version controlling everything, just what you've had
> > to change.  Of course, when the Cordova platform changes underneath you
> > (perhaps a new method is added to AppDelegate.m, and the version you have
> > in source control overwrites that), you need to check these files
> > carefully.  But when you version control everything and you upgrade, you
> > have to merge in your custom changes into the new Cordova code in the
> same
> > careful manner, plus you are carrying around everything else under
> > platforms.
> >
> > Of course, I'm a big believer in the CLI, having everyone use the entire
> > CLI toolchain, and treating everything under platforms and plugins as
> > derived code that you can replace at any time.  If this isn't how you
> > develop (if you prefer the 'native project dev' workflow, for example),
> > then this may not work for you.
> >
> > Thanks.
> > Dan
> >
> > PS Can you explain how keeping all the code in source control makes your
> > merges as you move from Cordova version to Cordova version easier?  To
> me,
> > that would seem to make them more difficult.
> >
> >
> >
> >
> >
> > On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> > kant2002@googlemail.com> wrote:
> >
> > About plugin and platform version control.
> > I heard a lot about that, and confused why you think that everybody would
> > like to remove ./plugins and ./platforms folders from source control. I
> do
> > agree that this is most likely the case for the simple applications and
> for
> > the maybe 99% of current Cordova users, but I don't believe that this is
> > truly important for the Cordova as the ecosystem for the cross-platform
> of
> > the mobile development.
> >
> > Let me explain why I think that keep ./platforms and ./plugins under
> source
> > control very important. I would base my reasoning on my current project
> > needs.
> > I currently develop 2 similar products for different clients from the
> same
> > domain. I understand that in future I will have another clients from same
> > problem domain which would like to have similar applications, just with
> > different design. So I take the route of having 1 product line and
> > customization of that product line for each client, depends on their
> needs.
> > This is client facing application, so I would like to cover as much
> mobile
> > platforms as possible with minimum amount of efforts. Currently I support
> > only Android and iOS platforms, but envision that my clients will expand
> to
> > the Windows Phone soon, and maybe I will force them to support Tizen in
> > next year if that platform would be world-wide popular.
> > I position my self as
> > a) heavy Cordova user
> > b) middle/low platform specific development. (I have to go deep in each
> > platform, but that's not priority for me as Cordova users)
> > I maintain 3 Git branches. 1 branch for core product and 2 branches for
> > each client. In each branch I keep, platform specific code for the
> > application (cordova-platform-ios/android code), Cordova plugins code +
> > plugins developed specifically to this application.
> > I definitely sure that I will need to add some functionality to the core
> > platforms, either iOS or Android which will benefit the my application. I
> > would try to push to the core Cordova as much as I can, but possible that
> > not all contribution would be useful for the Cordova. Either way I plan
> for
> > update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> > changes, which I add to current version of Cordova (3.3) and make update
> to
> > 3.4 and later easier I keep all code in the source control to make all my
> > future merges easier. Same rules apply to the plugins,maybe I add some
> > code/fixes to plugins, or not don't matter - I have to plan for that.
> > I would like to contribute to Cordova everything what will benefit the
> > community to meet my selfish goals:
> > I want to make my upgrade path as straightforward as possible, for
> platform
> > code and for plugins code.
> >
> > Maybe I was too verbose, but that was just to explain that I plan to
> align
> > my long-term goals with Cordova's long-term goals. I try to gave more
> > explanation, so you guys could plan not only for people which create
> > projects which are working on the specific version of Cordova, but also
> for
> > the guys which want to nurture their product together with Cordova.
> >
> > I plainly don't see:
> > a) how I could work on my product not keeping ./platforms and ./plugins
> > directories in the source control, and
> > b) why I should don't use Cordova CLI to update contents of my
> ./platforms
> > and ./plugins folders. I think that these tool has a good fit for basic
> > housekeeping of the files/plugins. Don't want to manually fiddle with
> > content of plugins for each platform and use plugman/cordova executables
> to
> > do the job.
> >
> > Hopefully I was enough verbose to explain why I have needs what I have
> now,
> > and not too verbose so you flood in details.
> >
> > To summarize my input is:
> > 1. Keep tools that way, that it could work either when ./plugins,
> > ./platforms in source control, or when these folders not in the VCS.
> > 2. Take into account that people may want to customize Cordova
> distribution
> > and have path to future upgrades.
> > 3. I want to take responsibility for some burden which this way could
> > potentially create for you guys,
> >
> > Andrey Kurdyumov.
> >
> >
> >
> >
> > 2014/1/7 Braden Shepherdson <br...@chromium.org>
> >
> > > I've wanted to add Cordova plugin dependencies to the app's top-level
> > > config.xml for a long time, but it's never reached the top of my
> > > priorities. I think with that support, we can avoid checking in
> > ./plugins/
> > > and ./platforms altogether for 99% of app developers. If it doesn't
> solve
> > > anyone's use case, I'd love to hear about it.
> > >
> > > Braden
> > >
> > >
> > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com>
> > wrote:
> > >
> > > > CB-4624 is exactly what I am looking for. I am not sure if it should
> be
> > > > config.xml or some other config file, it probably doesn't matter much
> > > when
> > > > it comes down to it. Is there any rules currently in place, like CLI
> > > > doesn't touch config.xml?
> > > >
> > > >
> > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <
> agrieve@chromium.org
> > > > >wrote:
> > > >
> > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> > relevant
> > > > > issue
> > > > > here. Please add comments to it if it's not spec'ed or good enough.
> > > > >
> > > > > Also related is https://issues.apache.org/jira/browse/CB-5006 -
> > meant
> > > to
> > > > > address local repos of plugins.
> > > > >
> > > > >
> > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > > kant2002@googlemail.com
> > > > > >wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Would be very helpful if you change formatting of the plugins
> > > manifest
> > > > > > files (android.json, ios.json). Currently it is print all JSON
> > string
> > > > to
> > > > > > the big single line, which difficult to merge when needed.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Ross Gerbasi <rg...@gmail.com>]

Hey Andrey,

Much like you said 99% of the users will want to ignore platforms and
plugins from version control. Making this work properly would not stop
someone from including them if they wanted to. If your workflow is better
including those folders you would have no problem doing so.

Ideally though if you can keep your custom code off in plugins, even if
they are not public plugins, would be ideal. Also as Dan mentioned you can
look into hooks to help modify platforms as needed.

Again though if you find checking everything in easier thats cool but the
CLI should be setup in a way that we do not need to.



On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <mo...@yahoo.com> wrote:

> Hi Andrey,
>
> I have worked on two small, simple Cordova applications, but we still at
> times had to modify platform specific code.  Not much, but some
> (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this
> is a 2.9.x project for now).
>
> Here's my solutions to your issues.
> * if you need to modify native plugin code, you should fork the repo and
> manage your changes via a git project, not in your project.
>
> If you use a recent enough version of Cordova, you can even pull plugins
> off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so
> you could have different versions of your apps for different clients pull
> different branches of the same plugin.
>
> * if you need to modify code under platforms, use an after_platform_add
> hook, and keep your customized platform files elsewhere in your project
> tree.
>
> This way, you aren't version controlling everything, just what you've had
> to change.  Of course, when the Cordova platform changes underneath you
> (perhaps a new method is added to AppDelegate.m, and the version you have
> in source control overwrites that), you need to check these files
> carefully.  But when you version control everything and you upgrade, you
> have to merge in your custom changes into the new Cordova code in the same
> careful manner, plus you are carrying around everything else under
> platforms.
>
> Of course, I'm a big believer in the CLI, having everyone use the entire
> CLI toolchain, and treating everything under platforms and plugins as
> derived code that you can replace at any time.  If this isn't how you
> develop (if you prefer the 'native project dev' workflow, for example),
> then this may not work for you.
>
> Thanks.
> Dan
>
> PS Can you explain how keeping all the code in source control makes your
> merges as you move from Cordova version to Cordova version easier?  To me,
> that would seem to make them more difficult.
>
>
>
>
>
> On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> kant2002@googlemail.com> wrote:
>
> About plugin and platform version control.
> I heard a lot about that, and confused why you think that everybody would
> like to remove ./plugins and ./platforms folders from source control. I do
> agree that this is most likely the case for the simple applications and for
> the maybe 99% of current Cordova users, but I don't believe that this is
> truly important for the Cordova as the ecosystem for the cross-platform of
> the mobile development.
>
> Let me explain why I think that keep ./platforms and ./plugins under source
> control very important. I would base my reasoning on my current project
> needs.
> I currently develop 2 similar products for different clients from the same
> domain. I understand that in future I will have another clients from same
> problem domain which would like to have similar applications, just with
> different design. So I take the route of having 1 product line and
> customization of that product line for each client, depends on their needs.
> This is client facing application, so I would like to cover as much mobile
> platforms as possible with minimum amount of efforts. Currently I support
> only Android and iOS platforms, but envision that my clients will expand to
> the Windows Phone soon, and maybe I will force them to support Tizen in
> next year if that platform would be world-wide popular.
> I position my self as
> a) heavy Cordova user
> b) middle/low platform specific development. (I have to go deep in each
> platform, but that's not priority for me as Cordova users)
> I maintain 3 Git branches. 1 branch for core product and 2 branches for
> each client. In each branch I keep, platform specific code for the
> application (cordova-platform-ios/android code), Cordova plugins code +
> plugins developed specifically to this application.
> I definitely sure that I will need to add some functionality to the core
> platforms, either iOS or Android which will benefit the my application. I
> would try to push to the core Cordova as much as I can, but possible that
> not all contribution would be useful for the Cordova. Either way I plan for
> update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> changes, which I add to current version of Cordova (3.3) and make update to
> 3.4 and later easier I keep all code in the source control to make all my
> future merges easier. Same rules apply to the plugins,maybe I add some
> code/fixes to plugins, or not don't matter - I have to plan for that.
> I would like to contribute to Cordova everything what will benefit the
> community to meet my selfish goals:
> I want to make my upgrade path as straightforward as possible, for platform
> code and for plugins code.
>
> Maybe I was too verbose, but that was just to explain that I plan to align
> my long-term goals with Cordova's long-term goals. I try to gave more
> explanation, so you guys could plan not only for people which create
> projects which are working on the specific version of Cordova, but also for
> the guys which want to nurture their product together with Cordova.
>
> I plainly don't see:
> a) how I could work on my product not keeping ./platforms and ./plugins
> directories in the source control, and
> b) why I should don't use Cordova CLI to update contents of my ./platforms
> and ./plugins folders. I think that these tool has a good fit for basic
> housekeeping of the files/plugins. Don't want to manually fiddle with
> content of plugins for each platform and use plugman/cordova executables to
> do the job.
>
> Hopefully I was enough verbose to explain why I have needs what I have now,
> and not too verbose so you flood in details.
>
> To summarize my input is:
> 1. Keep tools that way, that it could work either when ./plugins,
> ./platforms in source control, or when these folders not in the VCS.
> 2. Take into account that people may want to customize Cordova distribution
> and have path to future upgrades.
> 3. I want to take responsibility for some burden which this way could
> potentially create for you guys,
>
> Andrey Kurdyumov.
>
>
>
>
> 2014/1/7 Braden Shepherdson <br...@chromium.org>
>
> > I've wanted to add Cordova plugin dependencies to the app's top-level
> > config.xml for a long time, but it's never reached the top of my
> > priorities. I think with that support, we can avoid checking in
> ./plugins/
> > and ./platforms altogether for 99% of app developers. If it doesn't solve
> > anyone's use case, I'd love to hear about it.
> >
> > Braden
> >
> >
> > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com>
> wrote:
> >
> > > CB-4624 is exactly what I am looking for. I am not sure if it should be
> > > config.xml or some other config file, it probably doesn't matter much
> > when
> > > it comes down to it. Is there any rules currently in place, like CLI
> > > doesn't touch config.xml?
> > >
> > >
> > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > I think https://issues.apache.org/jira/browse/CB-4624 is the
> relevant
> > > > issue
> > > > here. Please add comments to it if it's not spec'ed or good enough.
> > > >
> > > > Also related is https://issues.apache.org/jira/browse/CB-5006 -
> meant
> > to
> > > > address local repos of plugins.
> > > >
> > > >
> > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > > kant2002@googlemail.com
> > > > >wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Would be very helpful if you change formatting of the plugins
> > manifest
> > > > > files (android.json, ios.json). Currently it is print all JSON
> string
> > > to
> > > > > the big single line, which difficult to merge when needed.
> > > > >
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Dan Moore <mo...@yahoo.com>]

Hi Andrey,

I have worked on two small, simple Cordova applications, but we still at times had to modify platform specific code.  Not much, but some (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this is a 2.9.x project for now).

Here's my solutions to your issues.
* if you need to modify native plugin code, you should fork the repo and manage your changes via a git project, not in your project.  

If you use a recent enough version of Cordova, you can even pull plugins off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so you could have different versions of your apps for different clients pull different branches of the same plugin.

* if you need to modify code under platforms, use an after_platform_add hook, and keep your customized platform files elsewhere in your project tree.  

This way, you aren't version controlling everything, just what you've had to change.  Of course, when the Cordova platform changes underneath you (perhaps a new method is added to AppDelegate.m, and the version you have in source control overwrites that), you need to check these files carefully.  But when you version control everything and you upgrade, you have to merge in your custom changes into the new Cordova code in the same careful manner, plus you are carrying around everything else under platforms. 

Of course, I'm a big believer in the CLI, having everyone use the entire CLI toolchain, and treating everything under platforms and plugins as derived code that you can replace at any time.  If this isn't how you develop (if you prefer the 'native project dev' workflow, for example), then this may not work for you.

Thanks.
Dan

PS Can you explain how keeping all the code in source control makes your merges as you move from Cordova version to Cordova version easier?  To me, that would seem to make them more difficult.





On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <ka...@googlemail.com> wrote:
 
About plugin and platform version control.
I heard a lot about that, and confused why you think that everybody would
like to remove ./plugins and ./platforms folders from source control. I do
agree that this is most likely the case for the simple applications and for
the maybe 99% of current Cordova users, but I don't believe that this is
truly important for the Cordova as the ecosystem for the cross-platform of
the mobile development.

Let me explain why I think that keep ./platforms and ./plugins under source
control very important. I would base my reasoning on my current project
needs.
I currently develop 2 similar products for different clients from the same
domain. I understand that in future I will have another clients from same
problem domain which would like to have similar applications, just with
different design. So I take the route of having 1 product line and
customization of that product line for each client, depends on their needs.
This is client facing application, so I would like to cover as much mobile
platforms as possible with minimum amount of efforts. Currently I support
only Android and iOS platforms, but envision that my clients will expand to
the Windows Phone soon, and maybe I will force them to support Tizen in
next year if that platform would be world-wide popular.
I position my self as
a) heavy Cordova user
b) middle/low platform specific development. (I have to go deep in each
platform, but that's not priority for me as Cordova users)
I maintain 3 Git branches. 1 branch for core product and 2 branches for
each client. In each branch I keep, platform specific code for the
application (cordova-platform-ios/android code), Cordova plugins code +
plugins developed specifically to this application.
I definitely sure that I will need to add some functionality to the core
platforms, either iOS or Android which will benefit the my application. I
would try to push to the core Cordova as much as I can, but possible that
not all contribution would be useful for the Cordova. Either way I plan for
update to next version of Cordova (3.4, or 3.5 whenether). To keep my
changes, which I add to current version of Cordova (3.3) and make update to
3.4 and later easier I keep all code in the source control to make all my
future merges easier. Same rules apply to the plugins,maybe I add some
code/fixes to plugins, or not don't matter - I have to plan for that.
I would like to contribute to Cordova everything what will benefit the
community to meet my selfish goals:
I want to make my upgrade path as straightforward as possible, for platform
code and for plugins code.

Maybe I was too verbose, but that was just to explain that I plan to align
my long-term goals with Cordova's long-term goals. I try to gave more
explanation, so you guys could plan not only for people which create
projects which are working on the specific version of Cordova, but also for
the guys which want to nurture their product together with Cordova.

I plainly don't see:
a) how I could work on my product not keeping ./platforms and ./plugins
directories in the source control, and
b) why I should don't use Cordova CLI to update contents of my ./platforms
and ./plugins folders. I think that these tool has a good fit for basic
housekeeping of the files/plugins. Don't want to manually fiddle with
content of plugins for each platform and use plugman/cordova executables to
do the job.

Hopefully I was enough verbose to explain why I have needs what I have now,
and not too verbose so you flood in details.

To summarize my input is:
1. Keep tools that way, that it could work either when ./plugins,
./platforms in source control, or when these folders not in the VCS.
2. Take into account that people may want to customize Cordova distribution
and have path to future upgrades.
3. I want to take responsibility for some burden which this way could
potentially create for you guys,

Andrey Kurdyumov.




2014/1/7 Braden Shepherdson <br...@chromium.org>

> I've wanted to add Cordova plugin dependencies to the app's top-level
> config.xml for a long time, but it's never reached the top of my
> priorities. I think with that support, we can avoid checking in ./plugins/
> and ./platforms altogether for 99% of app developers. If it doesn't solve
> anyone's use case, I'd love to hear about it.
>
> Braden
>
>
> On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com> wrote:
>
> > CB-4624 is exactly what I am looking for. I am not sure if it should be
> > config.xml or some other config file, it probably doesn't matter much
> when
> > it comes down to it. Is there any rules currently in place, like CLI
> > doesn't touch config.xml?
> >
> >
> > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > I think https://issues.apache.org/jira/browse/CB-4624 is the relevant
> > > issue
> > > here. Please add comments to it if it's not spec'ed or good enough.
> > >
> > > Also related is https://issues.apache.org/jira/browse/CB-5006 - meant
> to
> > > address local repos of plugins.
> > >
> > >
> > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > kant2002@googlemail.com
> > > >wrote:
> > >
> > > > Hi all,
> > > >
> > > > Would be very helpful if you change formatting of the plugins
> manifest
> > > > files (android.json, ios.json). Currently it is print all JSON string
> > to
> > > > the big single line, which difficult to merge when needed.
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Andrey Kurdumov <ka...@googlemail.com>]

About plugin and platform version control.
I heard a lot about that, and confused why you think that everybody would
like to remove ./plugins and ./platforms folders from source control. I do
agree that this is most likely the case for the simple applications and for
the maybe 99% of current Cordova users, but I don't believe that this is
truly important for the Cordova as the ecosystem for the cross-platform of
the mobile development.

Let me explain why I think that keep ./platforms and ./plugins under source
control very important. I would base my reasoning on my current project
needs.
I currently develop 2 similar products for different clients from the same
domain. I understand that in future I will have another clients from same
problem domain which would like to have similar applications, just with
different design. So I take the route of having 1 product line and
customization of that product line for each client, depends on their needs.
This is client facing application, so I would like to cover as much mobile
platforms as possible with minimum amount of efforts. Currently I support
only Android and iOS platforms, but envision that my clients will expand to
the Windows Phone soon, and maybe I will force them to support Tizen in
next year if that platform would be world-wide popular.
I position my self as
a) heavy Cordova user
b) middle/low platform specific development. (I have to go deep in each
platform, but that's not priority for me as Cordova users)
I maintain 3 Git branches. 1 branch for core product and 2 branches for
each client. In each branch I keep, platform specific code for the
application (cordova-platform-ios/android code), Cordova plugins code +
plugins developed specifically to this application.
I definitely sure that I will need to add some functionality to the core
platforms, either iOS or Android which will benefit the my application. I
would try to push to the core Cordova as much as I can, but possible that
not all contribution would be useful for the Cordova. Either way I plan for
update to next version of Cordova (3.4, or 3.5 whenether). To keep my
changes, which I add to current version of Cordova (3.3) and make update to
3.4 and later easier I keep all code in the source control to make all my
future merges easier. Same rules apply to the plugins,maybe I add some
code/fixes to plugins, or not don't matter - I have to plan for that.
I would like to contribute to Cordova everything what will benefit the
community to meet my selfish goals:
I want to make my upgrade path as straightforward as possible, for platform
code and for plugins code.

Maybe I was too verbose, but that was just to explain that I plan to align
my long-term goals with Cordova's long-term goals. I try to gave more
explanation, so you guys could plan not only for people which create
projects which are working on the specific version of Cordova, but also for
the guys which want to nurture their product together with Cordova.

I plainly don't see:
a) how I could work on my product not keeping ./platforms and ./plugins
directories in the source control, and
b) why I should don't use Cordova CLI to update contents of my ./platforms
and ./plugins folders. I think that these tool has a good fit for basic
housekeeping of the files/plugins. Don't want to manually fiddle with
content of plugins for each platform and use plugman/cordova executables to
do the job.

Hopefully I was enough verbose to explain why I have needs what I have now,
and not too verbose so you flood in details.

To summarize my input is:
1. Keep tools that way, that it could work either when ./plugins,
./platforms in source control, or when these folders not in the VCS.
2. Take into account that people may want to customize Cordova distribution
and have path to future upgrades.
3. I want to take responsibility for some burden which this way could
potentially create for you guys,

Andrey Kurdyumov.



2014/1/7 Braden Shepherdson <br...@chromium.org>

> I've wanted to add Cordova plugin dependencies to the app's top-level
> config.xml for a long time, but it's never reached the top of my
> priorities. I think with that support, we can avoid checking in ./plugins/
> and ./platforms altogether for 99% of app developers. If it doesn't solve
> anyone's use case, I'd love to hear about it.
>
> Braden
>
>
> On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com> wrote:
>
> > CB-4624 is exactly what I am looking for. I am not sure if it should be
> > config.xml or some other config file, it probably doesn't matter much
> when
> > it comes down to it. Is there any rules currently in place, like CLI
> > doesn't touch config.xml?
> >
> >
> > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > I think https://issues.apache.org/jira/browse/CB-4624 is the relevant
> > > issue
> > > here. Please add comments to it if it's not spec'ed or good enough.
> > >
> > > Also related is https://issues.apache.org/jira/browse/CB-5006 - meant
> to
> > > address local repos of plugins.
> > >
> > >
> > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> > kant2002@googlemail.com
> > > >wrote:
> > >
> > > > Hi all,
> > > >
> > > > Would be very helpful if you change formatting of the plugins
> manifest
> > > > files (android.json, ios.json). Currently it is print all JSON string
> > to
> > > > the big single line, which difficult to merge when needed.
> > > >
> > >
> >
>

Re: Plugin Version Control Workflow

[Braden Shepherdson <br...@chromium.org>]

I've wanted to add Cordova plugin dependencies to the app's top-level
config.xml for a long time, but it's never reached the top of my
priorities. I think with that support, we can avoid checking in ./plugins/
and ./platforms altogether for 99% of app developers. If it doesn't solve
anyone's use case, I'd love to hear about it.

Braden


On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rg...@gmail.com> wrote:

> CB-4624 is exactly what I am looking for. I am not sure if it should be
> config.xml or some other config file, it probably doesn't matter much when
> it comes down to it. Is there any rules currently in place, like CLI
> doesn't touch config.xml?
>
>
> On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I think https://issues.apache.org/jira/browse/CB-4624 is the relevant
> > issue
> > here. Please add comments to it if it's not spec'ed or good enough.
> >
> > Also related is https://issues.apache.org/jira/browse/CB-5006 - meant to
> > address local repos of plugins.
> >
> >
> > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> kant2002@googlemail.com
> > >wrote:
> >
> > > Hi all,
> > >
> > > Would be very helpful if you change formatting of the plugins manifest
> > > files (android.json, ios.json). Currently it is print all JSON string
> to
> > > the big single line, which difficult to merge when needed.
> > >
> >
>

Re: Plugin Version Control Workflow

[Ross Gerbasi <rg...@gmail.com>]

CB-4624 is exactly what I am looking for. I am not sure if it should be
config.xml or some other config file, it probably doesn't matter much when
it comes down to it. Is there any rules currently in place, like CLI
doesn't touch config.xml?


On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <ag...@chromium.org>wrote:

> I think https://issues.apache.org/jira/browse/CB-4624 is the relevant
> issue
> here. Please add comments to it if it's not spec'ed or good enough.
>
> Also related is https://issues.apache.org/jira/browse/CB-5006 - meant to
> address local repos of plugins.
>
>
> On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <kant2002@googlemail.com
> >wrote:
>
> > Hi all,
> >
> > Would be very helpful if you change formatting of the plugins manifest
> > files (android.json, ios.json). Currently it is print all JSON string to
> > the big single line, which difficult to merge when needed.
> >
>

Re: Plugin Version Control Workflow

[Andrew Grieve <ag...@chromium.org>]

I think https://issues.apache.org/jira/browse/CB-4624 is the relevant issue
here. Please add comments to it if it's not spec'ed or good enough.

Also related is https://issues.apache.org/jira/browse/CB-5006 - meant to
address local repos of plugins.


On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <ka...@googlemail.com>wrote:

> Hi all,
>
> Would be very helpful if you change formatting of the plugins manifest
> files (android.json, ios.json). Currently it is print all JSON string to
> the big single line, which difficult to merge when needed.
>

Re: Plugin Version Control Workflow

[Andrey Kurdumov <ka...@googlemail.com>]

Hi all,

Would be very helpful if you change formatting of the plugins manifest
files (android.json, ios.json). Currently it is print all JSON string to
the big single line, which difficult to merge when needed.

Re: Plugin Version Control Workflow

[Brian LeRoux <b...@brian.io>]

Also worth discussion, we might not want to add to the package manifests
situation with cordova.json. (This is pretending we don't have a bunch of
crazy config files laying around already! =)

Node has package.json works well for a `cordova install` use case. Though
Chrome Apps, and Firefox OS Apps are worth considering too. They are nearly
identical except Chrome uses manifest.json and Firefox manfiest.webapp.
Yay, config files.

\o/


On Mon, Dec 30, 2013 at 10:33 PM, Brian LeRoux <b...@brian.io> wrote:

> I do think getting the cli to the point where ./plugins, and ./platforms
> are recommended build artifacts is a goal we've always wanted.
>
> In context of Andrew's recent ./cordova.json proposal I think we can get
> rid of ./plugins fairly easy. If we list the dependencies (or
> devDependencies) we can create an equiv of `npm install` by just running a
> series of `cordova plugin add`.
>
>
>
>
> On Mon, Dec 30, 2013 at 9:58 PM, Jesse <pu...@gmail.com> wrote:
>
>> I'm sure users can figure out how to exclude the plugin folder, this seems
>> to be a simple matter of documenting what they should do.
>> Similarly, all native compiled platform projects have binary intermediate
>> cruft that should not be checked in, and we don't currently care ...
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Mon, Dec 30, 2013 at 5:03 PM, Ross Gerbasi <rg...@gmail.com> wrote:
>>
>> > Hey Gang,
>> >
>> > I think we need a better way to manage plugins across teams. I imagine
>> we
>> > don't want people checking the plugins folder into version control, I
>> would
>> > also think platforms should be ignored also. What do you all think about
>> > some kind of plugin manifest file and a install command. Something like
>> > nodes package.jsonn and npm install?
>> >
>>
>
>

Re: Plugin Version Control Workflow

[Brian LeRoux <b...@brian.io>]

I do think getting the cli to the point where ./plugins, and ./platforms
are recommended build artifacts is a goal we've always wanted.

In context of Andrew's recent ./cordova.json proposal I think we can get
rid of ./plugins fairly easy. If we list the dependencies (or
devDependencies) we can create an equiv of `npm install` by just running a
series of `cordova plugin add`.




On Mon, Dec 30, 2013 at 9:58 PM, Jesse <pu...@gmail.com> wrote:

> I'm sure users can figure out how to exclude the plugin folder, this seems
> to be a simple matter of documenting what they should do.
> Similarly, all native compiled platform projects have binary intermediate
> cruft that should not be checked in, and we don't currently care ...
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Dec 30, 2013 at 5:03 PM, Ross Gerbasi <rg...@gmail.com> wrote:
>
> > Hey Gang,
> >
> > I think we need a better way to manage plugins across teams. I imagine we
> > don't want people checking the plugins folder into version control, I
> would
> > also think platforms should be ignored also. What do you all think about
> > some kind of plugin manifest file and a install command. Something like
> > nodes package.jsonn and npm install?
> >
>

Re: Plugin Version Control Workflow

[Jesse <pu...@gmail.com>]

I'm sure users can figure out how to exclude the plugin folder, this seems
to be a simple matter of documenting what they should do.
Similarly, all native compiled platform projects have binary intermediate
cruft that should not be checked in, and we don't currently care ...

@purplecabbage
risingj.com


On Mon, Dec 30, 2013 at 5:03 PM, Ross Gerbasi <rg...@gmail.com> wrote:

> Hey Gang,
>
> I think we need a better way to manage plugins across teams. I imagine we
> don't want people checking the plugins folder into version control, I would
> also think platforms should be ignored also. What do you all think about
> some kind of plugin manifest file and a install command. Something like
> nodes package.jsonn and npm install?
>