Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of kant2002@googlemail.com
 designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAD66QQSwr9+LD_ehAymcW6yBp+fjg1iYbjajDvXtmNzAuOnp7Q@mail.gmail.com>
References: 
 <CAD66QQRY50b1nVpQnXvWsPkUgNA1uex-mA_njamY5Nhm80Vz0g@mail.gmail.com>
	<CAKP6k2vTEHfhUBMu2UYe-zLmGa-UqtkGK4oxCQS4eyPDSCf59g@mail.gmail.com>
	<CADVgkyN3=N_gE2ArBdf6Pasu1oGAHRNY-Jv_x-cHNCdoG4u-=A@mail.gmail.com>
	<CADVgkyMvtbfSzsOyijuY3m3Gob_NqUqgcwTZmstPw6f2xOJkqA@mail.gmail.com>
	<CAAY=exhG+Ekee9gCphxeNd6fT8ENBpuDZexCEYA-12-DJz=i9A@mail.gmail.com>
	<CABiQX1XtiZF1M=CZ2UpudC4v=dPcQmg8QjNHsGFdKkmJrPCm0w@mail.gmail.com>
	<CAD66QQS=3VptAMbb0-4CQuKW30mAamF3y5ZyHiZqSpMbig9HpQ@mail.gmail.com>
	<CAMk5LL=Ujf-06ceHsoPLfe-4V5zane-uSd_fRDbAN-WdhQAgmA@mail.gmail.com>
	<CAAY=exgT9y+Z4-r97mZCOqu-8NOAeZ+wBF+fR20m4DLZKEJ_Wg@mail.gmail.com>
	<1389056377.30579.YahooMailNeo@web163905.mail.gq1.yahoo.com>
	<CAD66QQSwr9+LD_ehAymcW6yBp+fjg1iYbjajDvXtmNzAuOnp7Q@mail.gmail.com>
Date: Tue, 7 Jan 2014 17:14:21 +0600
Message-ID: 
 <CAAY=exhcoCwyBh7oUKey-hE0UzbG0ovxbX7jQ61FFv5OVrE0qw@mail.gmail.com>
Subject: Re: Plugin Version Control Workflow
From: Andrey Kurdumov <kant2002@googlemail.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=047d7bdc9db26bf70d04ef5f7ae7

--047d7bdc9db26bf70d04ef5f7ae7
Content-Type: text/plain; charset=UTF-8

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 <rgerbasi@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 <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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

--047d7bdc9db26bf70d04ef5f7ae7--