cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Plugin Version Control Workflow
Date Tue, 07 Jan 2014 17:08:31 GMT
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 <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 <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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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