cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Deleting Plugin Docs
Date Fri, 13 Dec 2013 23:23:48 GMT
+1 from me, makes sense


On Fri, Dec 13, 2013 at 2:07 PM, Brian LeRoux <b@brian.io> wrote:

> ya I like that plan too
>
> README should just be simple description of what it is and how to install
>
> does raise the query: should plugin install automate config.xml tags?
>
>
> On Sat, Dec 14, 2013 at 8:22 AM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > Hi Andrew,
> >
> > I like this plan. It aligns perfectly with where I want the docs to go.
> >
> > I would rather see each plugin use a "doc/index.md" file for the API
> > documentation. However, since plugins.cordova.io should auto-generate
> the
> > README.md to HTML, it makes sense to use that file instead. However, I
> > would like to see any assets (images) or additional markdown files placed
> > in the "doc/" directory.
> >
> > Thanks for taking the lead on this one,
> > Michael
> >
> >
> > On Fri, Dec 13, 2013 at 1:09 PM, Brian LeRoux <b@brian.io> wrote:
> >
> > > +1
> > >
> > > (we should time this for the plugins.cordova.io refactor/release so we
> > > don't have a period of zero published plugin documentation)
> > >
> > >
> > > On Sat, Dec 14, 2013 at 6:47 AM, Andrew Grieve <agrieve@chromium.org>
> > > wrote:
> > >
> > > > On Fri, Dec 13, 2013 at 2:08 PM, Michal Mocny <mmocny@chromium.org>
> > > wrote:
> > > >
> > > > > RE my last suggest about CLI command for plugin docs, I'm now
> > thinking
> > > it
> > > > > would be better to do something like we plan for tests: ship an app
> > > that
> > > > > hosts the docs based on whichever plugins you have installed.
> >  Perhaps
> > > > the
> > > > > test app should even do both tasks?
> > > > >
> > > >
> > > > I think it'd be fine to think about this as a do-later thing, but I
> > don't
> > > > want to get side-tracked just yet with these kinds of possibilities.
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Fri, Dec 13, 2013 at 2:06 PM, Michal Mocny <mmocny@chromium.org
> >
> > > > wrote:
> > > > >
> > > > > > Mike, actually I think with this proposal it should be easier
> than
> > > ever
> > > > > to
> > > > > > match plugin to docs specific to its version.
> > > > > >
> > > > > > The documentation would come bundled with the plugin, so you
can
> > find
> > > > the
> > > > > > README.md alongside wherever your plugin code resides, be that
an
> > old
> > > > > > download, a plugman install, or from a git repo locally.
> > > > > >
> > > > > > Andrew, this all sounds pretty good, but looking forward to
> seeing
> > > > > Michael
> > > > > > Brooks/Brian chime in since I think they had a docs plan up
their
> > > > sleeve.
> > > > > >
> > > > > > Also, do we want to add a CLI command to show plugin docs?
> > > > > >
> > > > > > -Michal
> > > > > >
> > > > > >
> > > > > > On Fri, Dec 13, 2013 at 1:54 PM, Mike Billau <
> > mike.billau@gmail.com
> > > > > >wrote:
> > > > > >
> > > > > >> >> 2. Move plugin information found in cordova-docs
into a
> single
> > > > > >> README.md
> > > > > >> file within the respective plugin repos
> > > > > >> And also remove the /cordova/ folder from cordova-docs,
right?
> > This
> > > > way
> > > > > >> there will be only one single location for a plugin's
> > documentation
> > > > (the
> > > > > >> README.md file inside that plugin repo).
> > > > >
> > > > Right. The goal is one spot for plugin docs.
> > > >
> > > >
> > > > >  >>
> > > > > >> What will we do for docs of older versions? If somebody
is using
> > > 2.9,
> > > > > they
> > > > > >> will need the 2.9 README.md file - is it enough for them
to just
> > > > change
> > > > > >> the
> > > > > >> branch on github?
> > > > >
> > > > This change will not affect publish docs for older versions. for 2.9,
> > > you'd
> > > > still go to docs.cordova.io's 2.9 documentation.
> > > >
> > > >
> > > > > >>
> > > > > >> Assuming that there is no problem with viewing older
> > documentation,
> > > > then
> > > > > >> +1
> > > > > >> on all of these.
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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