cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo
Date Sat, 19 Oct 2013 19:24:52 GMT
Anis, when we were first ripping out the plugins getting ready for 3.0 we
didn't yet have support for plugins in git repo subdirs.  I think we had
that functionality by 3.0 launch but by then we have created a bunch of
repos and momentum followed through.  We *could* merge them all into a
cordova-plugins repo, but I'm not sure that has value.  We *could* graduate
plugins out of cordova-plugins into discrete repos, but I'm not sure that
has value either.  For end users, and for us devs, it really doesn't
matter, so we should do whats most comfortable.

Brian, at the moment we aren't using github for issue tracking anyway, so
"discrete issue tracking" doesn't need to mean "discrete git repo".  Likely
we do want to create a JIRA component for "graduated" plugins.  The only
benefit to moving to discrete repos I can think of is consistency, which
may very well have value (esp for tooling support like coho).

-Michal


On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b@brian.io> wrote:

> I think having a staging area for plugins is a good idea and leaving
> cordova-labs as a prototyping area. Ideally we graduate plugins out of
> cordova-plugins if they get any sort of traction at all and require
> discreet issue tracking.
>
>
> On Fri, Oct 18, 2013 at 1:31 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
>
> > I am just curious. Why do that only for those plugins only and not
> > every other plugins ? I know phonegap/phonegap-plugins was a bad idea
> > but since git 1.7 there is [1]. I've never used it but just figured it
> > might apply to our case. I also think namespacing is a bad idea.
> >
> > [1] http://schacon.github.io/git/git-read-tree.html#_sparse_checkout
> >
> > On Fri, Oct 18, 2013 at 12:57 PM, Shazron <shazron@gmail.com> wrote:
> > > Great -- i *think* we have consensus, but I will wait until Monday to
> > move
> > > forward just in case. Here's my updated proposal on what has been
> > discussed
> > > today:
> > >
> > > 1. Ask INFRA to create a cordova-plugins repo
> > > 2. Move (with history) the cordova-labs plugins branch to the repo in
> (1)
> > > 3. Create a CordovaPreferences plugin in (1) with a generic API (and
> > > predefined constants) -- iOS to start
> > >
> > >
> > > On Fri, Oct 18, 2013 at 11:46 AM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > >> Sure we can debate the exact interface when it comes to it.  Could use
> > >> predefined constants instead of strings to help with
> > >> typing/discoverability:
> > >>
> > >> navigator.cordovaPreferences.setPreference(win, fail,
> > >> navigator.cordovaPreferences.PREFERENCE-iOS-GapBetweenPages, 0);
> > >>
> > >>
> > >> On Fri, Oct 18, 2013 at 2:17 PM, Shazron <shazron@gmail.com> wrote:
> > >>
> > >> > Not feeling hot about the namespace thing - as Jesse said it might
> > limit
> > >> > us. Ok - if we do a cordova-plugins repo it won't be hard to move
> the
> > >> > plugins branch to it with a filter-branch option, preserving history
> > --
> > >> > great.
> > >> >
> > >> > I think a generic preferences plugin is ok  (wouldn't be hard to
> > convert
> > >> > the interface anyway for the existing code I have for iOS) with the
> > usual
> > >> > problems of user education/documentation for upgrades. Putting in
> the
> > >> > preference name itself might be error prone (who's a great speller
> > >> here?),
> > >> > but I would amend the pseudo code to actually have a failure/success
> > >> > callback as well for these situations.
> > >> >
> > >> > navigator.cordovaPreferences.setPreference(win, fail,
> > >> > 'iOS-GapBetweenPages",0);
> > >> > navigator.cordovaPreferences.getPreference(win, fail,
> > >> > 'iOS-GapBetweenPages");
> > >> >
> > >> > On Fri, Oct 18, 2013 at 10:59 AM, Jesse <purplecabbage@gmail.com>
> > wrote:
> > >> >
> > >> > > If you namespace it to the platform, and later it makes sense
to
> > >> support
> > >> > it
> > >> > > on another device, you will have even more issues.
> > >> > > I think the best approach mentioned is the cordova-plugins repo
> > which
> > >> is
> > >> > > like the wild-west that is purplecabbage/phonegap-plugins except
> it
> > is
> > >> > > managed by cordova contributors only.
> > >> > >
> > >> > > Another alternative is to create a generic 'preferences' plugin
> > which
> > >> IS
> > >> > > supported by all platforms, BUT the actual preferences differ
> > between
> > >> > > platforms.
> > >> > >
> > >> > > Something like:
> > >> > >
> navigator.cordovaPreferences.setPreference('iOS-GapBetweenPages",0);
> > >> > >
> > >> > >
> > >> > >
> > >> > > @purplecabbage
> > >> > > risingj.com
> > >> > >
> > >> > >
> > >> > > On Fri, Oct 18, 2013 at 10:45 AM, David Kemp <drkemp@google.com>
> > >> wrote:
> > >> > >
> > >> > > > I would hate to see plugins that are currently ios only
get put
> > >> there,
> > >> > > and
> > >> > > > then later have another platform supported. That would be
ugly.
> > >> > > >
> > >> > > > Can we at least insist that any plugin that goes in the
ios
> > platform
> > >> > > have a
> > >> > > > name like ios-* (likewise for other platforms)
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Oct 18, 2013 at 1:07 PM, Michal Mocny <
> > mmocny@chromium.org>
> > >> > > wrote:
> > >> > > >
> > >> > > > > +1 to metadata for repo location.
> > >> > > > >
> > >> > > > > However, I'm still not 100% why these plugins should
live in
> the
> > >> > > platform
> > >> > > > > repo?  Its just an arbitrary container, right?  I think
the
> fact
> > >> > thats
> > >> > > > its
> > >> > > > > a plugin is more relevant than the fact that they only
support
> > ios.
> > >> >  If
> > >> > > > > cordova-labs doesn't feel right, then why not make
a single
> > >> > > > cordova-plugins
> > >> > > > > repo?  I know we used to have a phonegap-plugins repo
and we
> > didn't
> > >> > > like
> > >> > > > > that, but thats because it had external contributions
and
> > >> unsupported
> > >> > > > stale
> > >> > > > > code.
> > >> > > > >
> > >> > > > > It doesn't really matter I guess, but I just don't
see the
> > point of
> > >> > > > having
> > >> > > > > seperated out all of the plugins into separate repos
and now
> we
> > >> shove
> > >> > > > some
> > >> > > > > back alongside platforms.
> > >> > > > >
> > >> > > > > -Michal
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, Oct 17, 2013 at 7:32 PM, Shazron <shazron@gmail.com>
> > >> wrote:
> > >> > > > >
> > >> > > > > > Also, to avoid any "git entanglements" with trying
to keep
> > >> history
> > >> > > > > between
> > >> > > > > > the two repos (it's possible but I'm not at level
of git
> > >> black-belt
> > >> > > > yet),
> > >> > > > > > I'm just going to copy the folders in, and add
them.
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Thu, Oct 17, 2013 at 4:11 PM, Shazron <shazron@gmail.com
> >
> > >> > wrote:
> > >> > > > > >
> > >> > > > > > > I propose moving these iOS only plugins to
the cordova-ios
> > >> repo,
> > >> > > and
> > >> > > > > > > adding the corresponding components in JIRA
> (ios-statusbar,
> > >> > > > > ios-keyboard)
> > >> > > > > > > for issue tracking.
> > >> > > > > > > With https://issues.apache.org/jira/browse/CB-5026
- plus
> > >> these
> > >> > > two
> > >> > > > > > > plugins, that would make a total of three
plugins in
> > >> cordova-ios
> > >> > > > > > (probably
> > >> > > > > > > in a plugins subfolder)
> > >> > > > > > >
> > >> > > > > > > Also, would be great to add the extra meta-data
(new
> tags?)
> > to
> > >> > > > > > plugins.xml
> > >> > > > > > > to show which repo this comes from, where
issues are
> > supposed
> > >> to
> > >> > > go.
> > >> > > > I
> > >> > > > > > > believe we discussed this in the hangout.
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

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