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 repo release
Date Mon, 25 Nov 2013 18:47:04 GMT
Super disagree about putting src into a single big repo. I get why we do
that. I do not buy that we 'have too many repos' or that complexity is
minimized by combining. Anyhow: not a discussion I think is even worth us
having AGAIN. =/


On Mon, Nov 25, 2013 at 10:32 AM, Braden Shepherdson <braden@chromium.org>wrote:

> Hang on a second:
>
> The release you send to the plugman registry doesn't care about git. You
> point it at a (sub)directory and it uploads the plugin. The version is set
> by the plugin.xml of that plugin.
>
> If we want tags for when those plugins were pushed to npm, what's wrong
> with tags like "whateverplugin-1.0.0"? It's a little cluttered to see all
> the tags for all the plugins, but you can still see all the releases of a
> given plugin. They're in this repo precisely because they're small or
> experimental and not ready for their own repos yet.
>
> -10 to one repo per plugin; we have way too many repos already, and this
> cordova-plugins repo is intended to be the catchall place for small and
> experimental plugins.
>
> Braden
>
>
>
>
> On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
>
> > Would that only be true if you shared readable tag names between plugins?
> >  If we used tags unique to each plugin, perhaps by prefixing tags with
> the
> > target plugins' name, then plugin releases would be isolated, right?
> >
> > -Michal
> >
> >
> > On Fri, Nov 22, 2013 at 8:02 PM, Jesse <purplecabbage@gmail.com> wrote:
> >
> > > The issue that if use a tag to signify the new version, then the tag is
> > > applied to all plugins in the repo. This is probably not a big deal for
> > > minor bumps, but when a plugin needs a major bump, they all will. So
> you
> > > will/could have a plugin with a major version bump even though the code
> > has
> > > not changed.
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > > > I don't understand, whats the problem?  I thought you publish plugins
> > by
> > > > git-repo & subdir & hash -- so multiple plugins makes no difference.
> > > >
> > > > The master & dev branch deal was to do with cordova-3.0 users that
> did
> > > not
> > > > support plugin repo install from !master branch, right?  But none of
> > > these
> > > > plugins in cordova-plugins existed back then, so we just set engine
> > > > requirement to 3.1?
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill <stevengill97@gmail.com
> >
> > > > wrote:
> > > >
> > > > > +1 on one plugin per repo. Would making releasing and tagging much
> > > > simpler.
> > > > >
> > > > >
> > > > > On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana <
> > csantana23@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > Yep that's the problem with having independent plugins in a
> single
> > > > repo,
> > > > > > and just using directories to separate them.
> > > > > >
> > > > > > If I would have a choice I would strongly encourage one plugin
> per
> > > repo
> > > > > > containing its own version and source control.
> > > > > >
> > > > > >
> > > > > > On Friday, November 22, 2013, Shazron wrote:
> > > > > >
> > > > > > > The cordova-plugins repo has plugins as well, but are outside
> of
> > > the
> > > > > > > purview of the planned weekly core plugins release - I
plan to
> > > upload
> > > > > > > independently.
> > > > > > >
> > > > > > > The repo does not have the concept of "dev" and "master"
> plugins
> > as
> > > > > well
> > > > > > > like the core plugins. It was suggested we have tags, but
this
> is
> > > > > > > problematic because we have multiple plugins in that one
repo.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Carlos Santana
> > > > > > <csantana23@gmail.com>
> > > > > >
> > > > >
> > > >
> > >
> >
>

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