cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Post 3.0.0 Releases - Plugins
Date Fri, 23 Aug 2013 13:55:46 GMT
+1 to that.


On Thu, Aug 22, 2013 at 9:40 PM, James Jong <wjamesjong@gmail.com> wrote:

> +1 to specifying plugins via tag/branch/hash.  Having master be the stable
> always felt a bit odd to me.
>
> I think once we have the ability to do this, we could set when to bump the
> version at stable release points.  I don't think we should be bumping for
> every single commit.
>
> -James Jong
>
> On Aug 22, 2013, at 1:48 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > I'm concerned about who decides when to bump semver version numbers for
> > plugins?  How do you define a feature, vs a bugfix?
> > non-backwards-compatible changes are easier to spot, but is a non-user
> > facing improvement a feature or bugfix, say, an api-compatible perf
> > improvement?  Plugging a stub implementation?  Adding error handling?
> >
> > Do we bump the version as part of each patch, or do we bump the version
> > once a week based on the changelog for the week prior?
> >
> > -Michal
> >
> >
> > On Mon, Aug 19, 2013 at 2:51 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> >
> >> Made an issue for this: https://issues.apache.org/jira/browse/CB-4622
> >>
> >>
> >> On Mon, Aug 19, 2013 at 9:55 AM, Ian Clelland <iclelland@chromium.org
> >>> wrote:
> >>
> >>> 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