Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.219.48 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CABiQX1WLR4M-LfpXDh8yDDkhmqpL5JWxOCKXHNkKwkp_OZ3CGg@mail.gmail.com>
References: 
 <CAKP6k2vrrcXC0yZ4X6ST7WWLUdSbELoeXKurFFap3ZvKwc8vvw@mail.gmail.com>
 <CAK_TSX+gXf2-FHp9XMjJ+oW=c1B=wxi4Nq+Ad35mWevfQnTn6Q@mail.gmail.com>
 <CABiQX1UsU1SJ-EKRyOSYXbVZfzerS0M_6MuKCvBSFDTHJDJF3A@mail.gmail.com>
 <CAK_TSXKTz_NWmCysjnKs3L1BV453q81zAMhNzA-x0E8O6xU5Hw@mail.gmail.com>
 <CABiQX1WLR4M-LfpXDh8yDDkhmqpL5JWxOCKXHNkKwkp_OZ3CGg@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Thu, 22 Aug 2013 13:48:45 -0400
Message-ID: 
 <CAEeF2Tc5TGOqLQZ-MXctCFf+1_DUeTyuthK6sFhSQ4CcJefh6g@mail.gmail.com>
Subject: Re: Post 3.0.0 Releases - Plugins
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c33676fdb1b504e48ce74c

--001a11c33676fdb1b504e48ce74c
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c33676fdb1b504e48ce74c--