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:55:42 GMT
On Mon, Aug 19, 2013 at 9:46 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> 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.
>

I think this is worth doing -- Jesse's point is valid, that *always*
requiring master to be stable imposes a lot on third-party developers.

If we can't pull anything but master, then we can't properly depend on
specific plugin revisions anyway, so it's going to be useful all around to
be able to name branches/tags.

And then we can decide for core plugins whether it makes sense to have the
master/dev split, or to do something different.

Ian


>
> 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