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 iclelland@google.com designates
 209.85.214.173 as permitted sender)
MIME-Version: 1.0
Sender: iclelland@google.com
In-Reply-To: 
 <CABiQX1UzQk1_OWzSb17Zk2Pyga6=URhhA5BmouFd29OVsTFi=w@mail.gmail.com>
References: 
 <CAKP6k2v3EvPZpU=9O_WhEf+LPD9erYqfSXaREm0aoKAcr4pUHw@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>
 <CAHYtTqm0f569cK24voCJOFNQdCA20RdCQnM5fkmgcLbz-dFdkQ@mail.gmail.com>
 <5357d001.c341420a.4ce1.6079@mx.google.com>
 <CAMk5LLkMSWcw-ZTsK1193BUDyAeQ+jNLopZJtueHN4m2KS59BA@mail.gmail.com>
 <535950B7.4000002@mozilla.com>
 <CABiQX1WsvaUfPTzDnXHiFaLHFZ3bwbddf7w-i_KB56Qj+o-ihQ@mail.gmail.com>
 <CAK_TSXLVEyDtu7GiPdBZvc+BoaOyka+GT4rLsyB=_Q0enBCVRA@mail.gmail.com>
 <CAEeF2TeecPr=gcOpUstiyUP3drnGPpXAQ0yPRkb2x8Ek9bNpGw@mail.gmail.com>
 <CABiQX1UzQk1_OWzSb17Zk2Pyga6=URhhA5BmouFd29OVsTFi=w@mail.gmail.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Fri, 25 Apr 2014 14:21:31 -0400
Message-ID: 
 <CAK_TSX+71Bhm8aRvR10s+=E859Nfs2BDXoBxne_ys7+k3ZsSNA@mail.gmail.com>
Subject: Re: [DISCUSS] Plugin master branches
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c30b0e2fff4504f7e20a57

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

This is now done. Buildbot will be broken until we update it to always use
master plugin branches; otherwise everything should be okay.

For the morbidly curious:

$ cordova-coho/coho repo-update -r plugins
$ cordova-coho/coho foreach -r plugins "git checkout master; git merge dev"
$ echo -e "\nThis is \`dev\` - the deprecated development branch of this
plugin; development of this plugin has moved to the \`master\` branch" >>
notice
$ cordova-coho/coho o foreach -r plugins "git checkout dev; git rm -r *;
git checkout HEAD -- README.md; cat ../notice >> README.md; git add
README.md; git commit -m 'CB-6521: Remove development branch'"
$ cordova-coho/coho repo-push -r plugins


On Fri, Apr 25, 2014 at 12:05 PM, Andrew Grieve <agrieve@chromium.org>wrote:

> Sounds good! There are a couple tweaks to coho to remove (yay) special
> casing of plugin repos. I can make that change once you're done.
>
> Go for a rm -r commit on dev instead of removing the HEAD right away,
> because I *think* if you delete the remote branch, then someone can
> easily (and accidentally) re-push their version of dev up.
>
>
> On Fri, Apr 25, 2014 at 11:47 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > On Fri, Apr 25, 2014 at 11:42 AM, Ian Clelland <iclelland@chromium.org
> >wrote:
> >
> >> I've created https://issues.apache.org/jira/browse/CB-6521 to track
> this
> >> now.
> >>
> >> My plan is to merge all of the dev branches into master, and push that.
> At
> >> that point, anyone pushing new changes can just push directly to master,
> >> and everything should be good.
> >>
> >> If I delete the dev branches immediately after doing that (really just
> the
> >> branch name, at that point), is that going to interfere with anyone's
> >> workflow? I hope that anyone with outstanding changes on a dev branch
> can
> >> just rebase them onto master after a git pull.
> >>
> >> Alternately, I can make a commit onto the dev branches that removes all
> of
> >> the code and replaces it with a "Development has moved to master" readme
> >> file. That should cause a good merge conflict for anyone trying to
> commit
> >> to dev after that point, and will stop people from accidentally
> recreating
> >> the dev branch when they go to push.
> >>
> > +1 to that idea.
> >
> >>
> >>
> >> On Thu, Apr 24, 2014 at 4:11 PM, Andrew Grieve <agrieve@chromium.org>
> >> wrote:
> >>
> >> > A good reference would be:
> >> >
> >> >
> >>
> https://github.com/apache/cordova-coho/blob/master/docs/committer-workflow.md
> >> >
> >> > On Thu, Apr 24, 2014 at 1:58 PM, Piotr Zalewa <pzalewa@mozilla.com>
> >> wrote:
> >> > > I think we should have a sane contributing to Cordova page which
> would
> >> > > explain which branch does what.
> >> > >
> >> > > I agree master is a default for a bleeding edge with tags
> representing
> >> > > current release.
> >> > >
> >> > > Dnia Thu Apr 24 11:56:45 2014 Braden Shepherdson pisze:
> >> > >
> >> > >> Standardizing the release tag names so that it can find the
> "latest"
> >> one
> >> > >> is
> >> > >> a can of worms I don't want us to open.
> >> > >>
> >> > >> The normal, standard flow is to install from the registry. If
> you're
> >> > using
> >> > >> the nonstandard git way, it's your job to pick the right branch,
> and
> >> > >> master
> >> > >> is the correct default. Choosing any other tag is much more
> surprising
> >> > >> than
> >> > >> using master when you're pulling from git with a bare URL.
> >> > >>
> >> > >> Users can already do "
> >> > >> https://github.com/apache/cordova-plugin-inappbrowser#commitish"
> (or
> >> > >> #:sub/dir, or #commitish:sub/dir). We support naming whatever
> branch,
> >> > tag,
> >> > >> or commit hash you like if you need something specific. master is
> the
> >> > sane
> >> > >> default.
> >> > >>
> >> > >> Braden
> >> > >>
> >> > >>
> >> > >> On Wed, Apr 23, 2014 at 10:36 AM, purplecabbage
> >> > >> <purplecabbage@gmail.com>wrote:
> >> > >>
> >> > >>>
> >> > >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <
> csantana23@gmail.com>
> >> > >>>
> >> > >>> wrote:
> >> > >>>>
> >> > >>>>
> >> > >>>> +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"
> >> > >>>
> >> > >>>
> >> > >>> Yes, this.
> >> > >>>
> >> > >>>>
> >> > >>>> --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>
> >> > >>>
> >> > >>>
> >> > >>
> >> > >
> >> > > --
> >> > > Piotr Zalewa
> >> > > Mozilla
> >> >
> >>
>

--001a11c30b0e2fff4504f7e20a57--