cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gerbasi <rgerb...@gmail.com>
Subject Re: Plugin Version Control Workflow
Date Tue, 07 Jan 2014 03:30:56 GMT
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 <moore234@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 <braden@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.
> > > > >
> > > >
> > >
> >
>

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