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 csantana23@gmail.com designates
 74.125.82.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEeF2Tdy0=jeH8Bg7QV1A-Fss1TAhGJjUHyS_2GF6vEh6O6BHA@mail.gmail.com>
References: 
 <CAKP6k2v3EvPZpU=9O_WhEf+LPD9erYqfSXaREm0aoKAcr4pUHw@mail.gmail.com>
	<CAK_TSX+xL4hqp4LLJ0rVZBK=rmQe_59UUkKMEPc6Aff7Pi1snQ@mail.gmail.com>
	<CAEeRA4o4o7SGPDE5f4TufvO+SEH8_LvNsmZG8XEhLAU5WjKwYw@mail.gmail.com>
	<CAMk5LLnUbezoY1HaR6GQr9trLsPh9iCCmZTxsP0fsnCq0ZD=aA@mail.gmail.com>
	<CABiQX1WQiAhqoht+nWOcgdJaNCq+ZYEffY0QBtHLE_s0Wtr7HA@mail.gmail.com>
	<3AAB22CF-B009-4977-AE8A-23A10A54984C@gmail.com>
	<CAMSbhBj6SHdvELjUBtVN3v0xvw2OOyb2S43uuj_Rboc56vdgvg@mail.gmail.com>
	<CAE6O_-bbbtnaKDc2uU_W5iYVq-dh=VCqH=8SN6wj39m0JoLWyg@mail.gmail.com>
	<CAOBL_k74LvEu06Kask8uy0cd60Li=JU5ZFDg-gFK3yRTmPpQZA@mail.gmail.com>
	<CANpVHHyQc5j193-GARo8Es03E21WPKGU4fK0joMiP0ovAZvjwg@mail.gmail.com>
	<CAE6O_-ZX-r27V5dTY2A3yBvLGa+zc4g9Vfg0xwGvk41OodH0ZA@mail.gmail.com>
	<CABiQX1XZvNT0q7VeyO0EqjNf9_M7vHpEJ9Ef31cT=7kuO3upgA@mail.gmail.com>
	<CAK_TSXLHSvEw4LV+58iZ8HZmfGqDSY4VN5cXj8do0P5ZHhqAMw@mail.gmail.com>
	<CAEeF2Tdy0=jeH8Bg7QV1A-Fss1TAhGJjUHyS_2GF6vEh6O6BHA@mail.gmail.com>
Date: Wed, 23 Apr 2014 10:16:06 -0400
Message-ID: 
 <CAHYtTqm0f569cK24voCJOFNQdCA20RdCQnM5fkmgcLbz-dFdkQ@mail.gmail.com>
Subject: Re: [DISCUSS] Plugin master branches
From: Carlos Santana <csantana23@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=f46d04389357926f2204f7b65f80

--f46d04389357926f2204f7b65f80
Content-Type: text/plain; charset=UTF-8

+1 on using one branch "master"

But, should we look into changing/enhancing the default behavior for "git"
plugin install implementation to:

if just a git url "https://github.com/apache/cordova-plugin-inappbrowser"
it will query the tags/releases, and not pull latest commit and instead
pull down latest release "r.0.4.0" from master.

Or it's not worth? user can just do "
https://github.com/apache/cordova-plugin-inappbrowser@r.0.4.0"

--Carlos


On Wed, Apr 23, 2014 at 9:30 AM, Michal Mocny <mmocny@chromium.org> wrote:

> Also, it will only "break" new plugin installs.
>
>
> On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > To be clear, this is just referring to Cordova CLI versions 3.0.0 -
> 3.0.4,
> > I think. By version 3.0.5, CLI had a dependency on plugman 0.10.0, which
> > included the "plugman-registry" branch. (We didn't push anything to the
> > registry until 3.1 was released, but we made sure that the infrastructure
> > was ready a while before).
> >
> > If it is possible to use later versions of cordova-cli on a project that
> > uses Cordova 3.0 engines, then we should be clear that we're not breaking
> > Cordova 3.0 projects; just the oldest versions of the CLI, which
> developers
> > should be encouraged to upgrade in any case.
> >
> >
> >
> > On Tue, Apr 22, 2014 at 9:00 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > Didn't know about npm deprecate. Makes sense to me!
> > >
> > > On Tue, Apr 22, 2014 at 7:09 PM, Shazron <shazron@gmail.com> wrote:
> > > > Can we deprecate version 3.0?
> > > > https://www.npmjs.org/doc/cli/npm-deprecate.html
> > > >
> > > >
> > > > On Tue, Apr 22, 2014 at 4:00 PM, Anis KADRI <anis.kadri@gmail.com>
> > > wrote:
> > > >
> > > >> +1 as well. This will break Cordova 3.0 though. Cordova versions >=
> > 3.1
> > > are
> > > >> fine because they support registries. Cordova 3.0 only supports git
> > and
> > > can
> > > >> only fetch from master branches.
> > > >>
> > > >>
> > > >> On Tue, Apr 22, 2014 at 11:32 AM, Joe Bowser <bowserj@gmail.com>
> > wrote:
> > > >>
> > > >> > +1
> > > >> >
> > > >> > On Tue, Apr 22, 2014 at 11:30 AM, Shazron <shazron@gmail.com>
> > wrote:
> > > >> > > +1++
> > > >> > >
> > > >> > >
> > > >> > > On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill <
> > > stevengill97@gmail.com
> > > >> > >wrote:
> > > >> > >
> > > >> > >> +1!
> > > >> > >>
> > > >> > >>
> > > >> > >> On Tue, Apr 22, 2014 at 10:02 AM, James Jong <
> > wjamesjong@gmail.com
> > > >
> > > >> > wrote:
> > > >> > >>
> > > >> > >> > +1 Making it easier and less confusing for our new
> contributors
> > > is
> > > >> > good.
> > > >> > >> > -James Jong
> > > >> > >> >
> > > >> > >> > On Apr 22, 2014, at 12:07 PM, Andrew Grieve <
> > > agrieve@chromium.org>
> > > >> > >> wrote:
> > > >> > >> >
> > > >> > >> > > +1! Certainly it's causing us a lot of pain still. Moving
> to
> > > >> > releasing
> > > >> > >> > off
> > > >> > >> > > of master seems like it would work fine. It's been working
> > fine
> > > >> for
> > > >> > >> > > CLI/plugman, and they move much faster.
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> > > On Tue, Apr 22, 2014 at 11:37 AM, Braden Shepherdson <
> > > >> > >> > braden@chromium.org>wrote:
> > > >> > >> > >
> > > >> > >> > >> We originally needed the plugin releases to be on the
> master
> > > >> branch
> > > >> > >> > because
> > > >> > >> > >> there was no way to have CLI/Plugman fetch from other
> > > branches.
> > > >> > That
> > > >> > >> is
> > > >> > >> > no
> > > >> > >> > >> longer the case. Further, you're correct that the
> registry's
> > > >> > tarballs
> > > >> > >> is
> > > >> > >> > >> the primary source now. Even if someone does have a git
> > > >> dependency
> > > >> > >> > >> somewhere, they can specify a branch (actually any ref) in
> > the
> > > >> > >> > <dependency>
> > > >> > >> > >> tag. Likewise the command line.
> > > >> > >> > >>
> > > >> > >> > >> I'm all for moving development into the master branch.
> > > >> > >> > >>
> > > >> > >> > >> Braden
> > > >> > >> > >>
> > > >> > >> > >>
> > > >> > >> > >> On Tue, Apr 22, 2014 at 10:23 AM, Bryan Higgins <
> > > >> > >> bryan@bryanhiggins.net
> > > >> > >> > >>> wrote:
> > > >> > >> > >>
> > > >> > >> > >>> +1
> > > >> > >> > >>>
> > > >> > >> > >>> I think the registry has been around for long enough that
> > the
> > > >> vast
> > > >> > >> > >> majority
> > > >> > >> > >>> of users won't be installing directly from git.
> > > >> > >> > >>>
> > > >> > >> > >>>
> > > >> > >> > >>> On Tue, Apr 22, 2014 at 9:44 AM, Ian Clelland <
> > > >> > >> iclelland@chromium.org
> > > >> > >> > >>>> wrote:
> > > >> > >> > >>>
> > > >> > >> > >>>> I totally agree that we should do this.
> > > >> > >> > >>>>
> > > >> > >> > >>>> I think that once the current plugin release is
> complete,
> > I
> > > can
> > > >> > set
> > > >> > >> up
> > > >> > >> > >>> the
> > > >> > >> > >>>> branches so that the master branch is for development,
> and
> > > we
> > > >> > can go
> > > >> > >> > >> from
> > > >> > >> > >>>> there.
> > > >> > >> > >>>>
> > > >> > >> > >>>> Is it a requirement that plugins be tagged in git for
> npm
> > to
> > > >> > >> function?
> > > >> > >> > >> I
> > > >> > >> > >>>> thought that the plugins were uploaded, zipped, to our
> > couch
> > > >> > server,
> > > >> > >> > >> for
> > > >> > >> > >>>> each release, and that there was no further
> communication
> > > with
> > > >> > the
> > > >> > >> git
> > > >> > >> > >>>> repository? It shouldn't be a problem to go back and
> make
> > > sure
> > > >> > >> they're
> > > >> > >> > >>>> properly tagged, but I'm just wondering if it's still a
> > > >> > necessity.
> > > >> > >> > >>>>
> > > >> > >> > >>>> Ian
> > > >> > >> > >>>>
> > > >> > >> > >>>> On Mon, Apr 21, 2014 at 9:27 PM, Jesse <
> > > >> purplecabbage@gmail.com>
> > > >> > >> > >> wrote:
> > > >> > >> > >>>>
> > > >> > >> > >>>>> I am seeing more and more pull requests that aren't
> easy
> > > >> merges
> > > >> > >> > >> because
> > > >> > >> > >>>>> people are starting their work from the master branch,
> > and
> > > not
> > > >> > dev.
> > > >> > >> > >>>>>
> > > >> > >> > >>>>> We discussed *a long time ago* that at some point, we
> > would
> > > >> > >> consider
> > > >> > >> > >>>> master
> > > >> > >> > >>>>> to be the bleeding edge of each plugin, and we could
> then
> > > get
> > > >> > rid
> > > >> > >> of
> > > >> > >> > >>> the
> > > >> > >> > >>>>> dev branches.  The requirements to make this possible
> > > >> included,
> > > >> > >> > >> using a
> > > >> > >> > >>>>> branch/tag for every npm release of the plugin, and
> > making
> > > >> sure
> > > >> > >> that
> > > >> > >> > >>>> plugin
> > > >> > >> > >>>>> dependencies were correctly mapped.
> > > >> > >> > >>>>>
> > > >> > >> > >>>>> Has anyone given this any more thought, and do we have
> > any
> > > >> idea
> > > >> > >> when
> > > >> > >> > >> we
> > > >> > >> > >>>>> will make the switch?
> > > >> > >> > >>>>>
> > > >> > >> > >>>>> Cheers,
> > > >> > >> > >>>>>  Jesse
> > > >> > >> > >>>>>
> > > >> > >> > >>>>>
> > > >> > >> > >>>>> @purplecabbage
> > > >> > >> > >>>>> risingj.com
> > > >> > >> > >>>>>
> > > >> > >> > >>>>
> > > >> > >> > >>>
> > > >> > >> > >>
> > > >> > >> >
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> > >
> >
>


-- 
Carlos Santana
<csantana23@gmail.com>

--f46d04389357926f2204f7b65f80--