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 Mon, 04 Nov 2013 21:49:30 GMT
woo-hoo finally!


On Mon, Nov 4, 2013 at 4:06 PM, Shazron <shazron@gmail.com> wrote:

> cordova-plugins repo created
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;a=summary
>
> I'll start migrating by EOD cordova-labs/#plugins
>
>
> On Mon, Oct 21, 2013 at 9:13 AM, Shazron <shazron@gmail.com> wrote:
>
> > INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902
> >
> >
> > On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux <b@brian.io> wrote:
> >
> >> Discreet repos do have value for discreet issue tracking IMO even when
> you
> >> use Jira. For example, feature branching is easier to reason about.
> >>
> >>  /me shrugs
> >>
> >> One big repo to rule them all has created more problems than perceived
> >> benifits in our past experience so maybe I'm just allergic.
> >>
> >> On Saturday, October 19, 2013, Michal Mocny wrote:
> >>
> >> > 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
> >> > > > i
> >>
> >
> >
>

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