cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Post 3.0.0 Releases - Plugins
Date Mon, 19 Aug 2013 13:46:51 GMT
Yes, sorry for not being clear - this is all entirely about our own plugins.

I liked everything you said Jesse. Only reason I'm suggesting dev vs master
is because right now that's how plugman works (pulls from master). If we
change plugman to look for a tag (like npm
install<https://npmjs.org/doc/cli/npm-install.html>does), then we can
change our branch structure.


On Mon, Aug 19, 2013 at 9:23 AM, Ian Clelland <iclelland@chromium.org>wrote:

> On Mon, Aug 19, 2013 at 4:29 AM, Jesse <purplecabbage@gmail.com> wrote:
>
> > Okay, took me awhile to get this out, I should know better than to
> promise
> > to start a new threads on Friday afternoon. XD
> >
> > Split from 'Releases in a 3.0 World'
> >
> > RE: Pasted =>
> >
> > > cordova-plugins:
> > >  - Commit only to the `dev` branch
> > >  - Use semver for them.
> > ...
>
> I don't think that we should dictate what we expect the community to do
> > with their own plugins. Here's some alternative thoughts:
> >
>
> All good ideas, I think. To be fair, though, I think that Andrew's original
> proposal was specifically about core plugins, and how we version / release
> those.
>
> >
> > a) versioning is done however the developer of the plugin wants to do it,
> > for core plugins, because they are within our control and we ARE 'the
> > developer' we will use semver.
> >
>
> Agreed. See above.
>
>
> > b) plugman needs to gain the ability to install any particular version
> of a
> > plugin, just like a plugin can depend on a specific version of another
> > plugin, we need to be able do this directly.
> >
>
> Probably some kind of standard git url that names both the repo and the
> branch / tag.
>
>
> > c) do not enforce the use of a dev branch, master should be considered a
> > work in progress, we have already had issues where 1 broken push to
> master
> > [1] broke the plugin for all platforms.
> >
>
> This will probably depend on (b), although we could also get the same
> effect by developing on master, and having plugman pull from a named
> "stable" branch (or some other named branch). Of course, if we want to
> support third-party plugins as well, without dictating to them, then we
> should probably be able to just tell plugman which branch to pull from for
> any given plugin.
>
>
> > -  My personal expectation of a 'master' branch is that tests are
> passing,
> > but it is still the bleeding edge, and I should use it at my own risk.
> > -  If we want to suggest a tested latest version, in production, I think
> we
> > should use a tag or branch of 'latest-stable' or something similar.
> > - also, plugman should be aware of version via tags or branches, and not
> > blindly pull from master, this would likely be handled at plugin
> > registration time.  ( as in b above ) Then we can test a plugin's
> > integration with other plugins before pushing it live.
> >
> > The rest of the initial proposal is about process, which I don't think we
> > govern for plugin developers.  We can certainly adopt something like this
> > for the core plugins, but I think we should let the process evolve, and
> not
> > pretend we know what will happen next.
> >
> > I am not completely sold on the above, some of this is just me thinking
> out
> > loud, the main thing I worry is just that we may not have enough info to
> > fully define this ( at least the process stuff), and I think it
> definitely
> > needs more discussion, and even maybe some experimentation.
> >
>
> Ian
>

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