cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Post 3.0.0 Releases - Plugins
Date Mon, 19 Aug 2013 13:23:42 GMT
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