cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [cordova-plugins/statusbar] Publishing as core
Date Mon, 10 Mar 2014 15:45:07 GMT
I like it. Statusbar is considered core by the community. That said, should
it be rolled into the platform as a feature?


On Mon, Mar 10, 2014 at 7:39 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> What does core mean?
>
> Does "core" mean that it has the namespace "org.apache.cordova."?
> Does "core" mean that it is something we will support?
> Does "core" mean that it is something that applies to multiple platforms?
>
>
> I would like "core" to be the first two. And by "we", I mean at least one
> committer. That's generally how platforms have worked (if no committers is
> interested in maintaining them, then they don't get worked on. Otherwise,
> they do).
>
> I do also like the idea of a "org.apache.cordova.labs" namespace. We could
> use it to mean that it's something we are thinking about being "core" in
> the future, but it's at risk of changing (e.g. API fluctuation), or of us
> deciding it's not actually worth our time to support.
>
> I would put statusbar as "core" given the stated importance of it so far,
> and given that multiple people are willing to work on it.
>
> I would put keyboard as "labs" due to the current quality of it (serious
> iOS7 bugs, unsolved dead-zone when removing accessory).
>
>
>
>
>
>
> On Fri, Mar 7, 2014 at 7:31 PM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > StatusBar wp7+8 is mostly done. Just testing some stuff now.
> >
> > Sent from my iPhone
> >
> > > On Mar 7, 2014, at 3:30 PM, Shazron <shazron@gmail.com> wrote:
> > >
> > > Technically there are two platforms right now. Android has minimal
> > support,
> > > and Jesse wants to do WP8 (again minimal), so thats another.
> > >
> > >
> > >> On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <anis.kadri@gmail.com>
> > wrote:
> > >>
> > >> +1 for labs. it doesn't really make sense to have them in core if they
> > only
> > >> support one platform.
> > >>
> > >>
> > >>> On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wjamesjong@gmail.com>
> > wrote:
> > >>>
> > >>> Similar to keyboard plugin, I like the idea of letting this bake in
> > labs
> > >>> for now and moving them into core if we see multiple platforms start
> > >>> needing a similar API.  So (a) and (c) for me.
> > >>>
> > >>> I would add that the iOS 6/7 specific code may not make sense as
> > "core".
> > >>>
> > >>> -James Jong
> > >>>
> > >>>> On Mar 5, 2014, at 9:10 PM, Jesse <purplecabbage@gmail.com>
wrote:
> > >>>>
> > >>>> I have created a task in JIRA for all the statusbar related
> > discussion.
> > >>> [1]
> > >>>> There are numerous inconsistencies we need to address here.
> > >>>>
> > >>>> [1] https://issues.apache.org/jira/browse/CB-6177
> > >>>>
> > >>>> @purplecabbage
> > >>>> risingj.com
> > >>>>
> > >>>>
> > >>>>> On Wed, Mar 5, 2014 at 5:15 PM, Shazron <shazron@gmail.com>
wrote:
> > >>>>>
> > >>>>> Some background on the statusbar plugin.
> > >>>>>
> > >>>>> This was conceived because of iOS 7 where the statusbar overlays
> the
> > >>>>> webview, and a lot of people didn't like their UI changing
> especially
> > >> if
> > >>>>> they still support iOS 6. That is the primary purpose of this
> plugin,
> > >>> but
> > >>>>> there are other features in there as well. In the last few
weeks,
> > >> there
> > >>> was
> > >>>>> a pull request (now integrated) for StatusBar.hide and
> StatusBar.show
> > >>> for
> > >>>>> Android as well.
> > >>>>>
> > >>>>> The issues related to the statusbar are under the label
> > >>> "statusbar-plugin"
> > >>>>> in JIRA, and there are currently 11 open issues. There are
pull
> > >> requests
> > >>>>> for it from the PhoneGap Build team that I am waiting to integrate
> --
> > >>> not
> > >>>>> until we get this namespace stuff sorted out.
> > >>>>>
> > >>>>> I am not opposed to it being under the "labs" namespace. After
> > talking
> > >>> to
> > >>>>> the Adobe team, we could also host the plugin under the PhoneGap
> > >> Github
> > >>>>> org, but I'd rather use that as a last resort.
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mmocny@chromium.org
> >
> > >>> wrote:
> > >>>>>
> > >>>>>> (a) Yes.
> > >>>>>> (b) No -- some organizations (Adobe) don't like this, and
we
> respect
> > >>>>> that.
> > >>>>>> We also want to point users at these plugins, so its good
to have
> > >>>>>> developers protected by Apache.
> > >>>>>> (c) Sure -- so long as labs is clearly separate, and we
leave them
> > >> out
> > >>> of
> > >>>>>> blogs / plugin release notes, and we don't impact the rate
of
> > >> releases
> > >>>>>> (i.e. we don't force devs to test the labs plugins, just
verify
> the
> > >>>>>> signatures is enough).
> > >>>>>> (d) I think the "guardian" of these labs plugins should
be free to
> > >>>>> publish.
> > >>>>>> There is no reason they are lower quality than anything
else.
> > >>>>>>
> > >>>>>>
> > >>>>>> Separate issue: is statusbar ready for Core?  I think we
should
> > leave
> > >>> it
> > >>>>> in
> > >>>>>> labs for a little bit, have at least a few eyes audit the
API and
> > >>>>>> investigate if there is any other similar work in the field
before
> > we
> > >>>>> make
> > >>>>>> users depend on this, but that it should move to core eventually.
> > >>>>>>
> > >>>>>> -Michal
> > >>>>>>
> > >>>>>>
> > >>>>>>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <shazron@apache.org>
> > wrote:
> > >>>>>>>
> > >>>>>>> statusbar is already published org.apache.cordova.statusbar.
> > >>>>>>>
> > >>>>>>> And... Since these plugins are somewhat experimental
and we're
> > >>> starting
> > >>>>>> the
> > >>>>>>> process of voting and publishing plugins to dist/,
I wonder:
> > >>>>>>>
> > >>>>>>> a) Should we change the ID of these plugins to, say
> > >>>>>>> "org.apache.cordova.labs"
> > >>>>>>> b) Should we move these plugins to github and have
them not under
> > >>>>> apache
> > >>>>>>> for now, e.g.: com.shazron.statusbar
> > >>>>>>> c) Should we just add them to the plugin release process.
> > >>>>>>> d) Should we just never publish them to the registry
and have
> > people
> > >>>>> use
> > >>>>>>> them via git url.
> > >>
> >
>

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