You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2014/04/22 03:27:16 UTC

[DISCUSS] Plugin master branches

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

Re: [DISCUSS] Plugin master branches

Posted by Ian Clelland <ic...@google.com>.

Thanks for catching that, Andrey. I'll look into it.

Ian

On Saturday, April 26, 2014, Andrey Kurdumov <ka...@googlemail.com>
wrote:

> Currently documentation for plugins is broken.on both edge and 3.4
> versions, because links pointed to no longer existed branch in GitHub.
> I file issue CB-6530 for that.
>
>
> 2014-04-26 0:21 GMT+06:00 Ian Clelland <iclelland@chromium.org<javascript:;>
> >:
>
> > 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 <mm...@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

Re: [DISCUSS] Plugin master branches

Posted by Andrey Kurdumov <ka...@googlemail.com>.

Currently documentation for plugins is broken.on both edge and 3.4
versions, because links pointed to no longer existed branch in GitHub.
I file issue CB-6530 for that.


2014-04-26 0:21 GMT+06:00 Ian Clelland <ic...@chromium.org>:

> 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 <mm...@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 <ag...@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 <pz...@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
> > >> > >> <pu...@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
> > >> > >>>> <cs...@gmail.com>
> > >> > >>>
> > >> > >>>
> > >> > >>
> > >> > >
> > >> > > --
> > >> > > Piotr Zalewa
> > >> > > Mozilla
> > >> >
> > >>
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Ian Clelland <ic...@chromium.org>.

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 <ag...@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 <mm...@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 <ag...@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 <pz...@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
> >> > >> <pu...@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 <sh...@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
> >> > >>>> <cs...@gmail.com>
> >> > >>>
> >> > >>>
> >> > >>
> >> > >
> >> > > --
> >> > > Piotr Zalewa
> >> > > Mozilla
> >> >
> >>
>

Re: [DISCUSS] Plugin master branches

Posted by Andrew Grieve <ag...@chromium.org>.

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 <mm...@chromium.org> wrote:
> On Fri, Apr 25, 2014 at 11:42 AM, Ian Clelland <ic...@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 <ag...@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 <pz...@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
>> > >> <pu...@gmail.com>wrote:
>> > >>
>> > >>>
>> > >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <sh...@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 <sh...@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
>> > >>>> <cs...@gmail.com>
>> > >>>
>> > >>>
>> > >>
>> > >
>> > > --
>> > > Piotr Zalewa
>> > > Mozilla
>> >
>>

Re: [DISCUSS] Plugin master branches

Posted by Michal Mocny <mm...@chromium.org>.

On Fri, Apr 25, 2014 at 11:42 AM, Ian Clelland <ic...@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 <ag...@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 <pz...@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
> > >> <pu...@gmail.com>wrote:
> > >>
> > >>>
> > >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <sh...@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 <sh...@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
> > >>>> <cs...@gmail.com>
> > >>>
> > >>>
> > >>
> > >
> > > --
> > > Piotr Zalewa
> > > Mozilla
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Ian Clelland <ic...@chromium.org>.

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.


On Thu, Apr 24, 2014 at 4:11 PM, Andrew Grieve <ag...@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 <pz...@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
> >> <pu...@gmail.com>wrote:
> >>
> >>>
> >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <mm...@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 <sh...@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 <bo...@gmail.com>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
> >>>> <cs...@gmail.com>
> >>>
> >>>
> >>
> >
> > --
> > Piotr Zalewa
> > Mozilla
>

Re: [DISCUSS] Plugin master branches

Posted by Andrew Grieve <ag...@chromium.org>.

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 <pz...@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
>> <pu...@gmail.com>wrote:
>>
>>>
>>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <mm...@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 <ag...@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Didn't know about npm deprecate. Makes sense to me!
>>>>>>>
>>>>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com>
>>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
>>>> <cs...@gmail.com>
>>>
>>>
>>
>
> --
> Piotr Zalewa
> Mozilla

Re: [DISCUSS] Plugin master branches

Posted by Piotr Zalewa <pz...@mozilla.com>.

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 <pu...@gmail.com>wrote:
>
>>
>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <mm...@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 <ag...@chromium.org>
>>>>> wrote:
>>>>>
>>>>>> Didn't know about npm deprecate. Makes sense to me!
>>>>>>
>>>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
>>> <cs...@gmail.com>
>>
>

--
Piotr Zalewa
Mozilla

Re: [DISCUSS] Plugin master branches

Posted by Braden Shepherdson <br...@chromium.org>.

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 <pu...@gmail.com>wrote:

>
> > On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <mm...@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 <ag...@chromium.org>
> >>> wrote:
> >>>
> >>>> Didn't know about npm deprecate. Makes sense to me!
> >>>>
> >>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com>
> >>> wrote:
> >>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
> > <cs...@gmail.com>
>

Re: [DISCUSS] Plugin master branches

Posted by purplecabbage <pu...@gmail.com>.

> On Apr 23, 2014, at 7:16 AM, Carlos Santana <cs...@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 <mm...@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 <ag...@chromium.org>
>>> wrote:
>>> 
>>>> Didn't know about npm deprecate. Makes sense to me!
>>>> 
>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com>
>>> wrote:
>>>>>> 
>>>>>>> +1
>>>>>>> 
>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
> <cs...@gmail.com>

Re: [DISCUSS] Plugin master branches

Posted by Carlos Santana <cs...@gmail.com>.

+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 <mm...@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 <ag...@chromium.org>
> > wrote:
> >
> > > Didn't know about npm deprecate. Makes sense to me!
> > >
> > > On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com>
> > wrote:
> > > >>
> > > >> > +1
> > > >> >
> > > >> > On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
<cs...@gmail.com>

Re: [DISCUSS] Plugin master branches

Posted by Michal Mocny <mm...@chromium.org>.

Also, it will only "break" new plugin installs.


On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland <ic...@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 <ag...@chromium.org>
> wrote:
>
> > Didn't know about npm deprecate. Makes sense to me!
> >
> > On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com>
> wrote:
> > >>
> > >> > +1
> > >> >
> > >> > On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
> > >> > >> > >>>>>
> > >> > >> > >>>>
> > >> > >> > >>>
> > >> > >> > >>
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Ian Clelland <ic...@chromium.org>.

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 <ag...@chromium.org> wrote:

> Didn't know about npm deprecate. Makes sense to me!
>
> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com> wrote:
> >>
> >> > +1
> >> >
> >> > On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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
> >> > >> > >>>>>
> >> > >> > >>>>
> >> > >> > >>>
> >> > >> > >>
> >> > >> >
> >> > >> >
> >> > >>
> >> >
> >>
>

Re: [DISCUSS] Plugin master branches

Posted by Andrew Grieve <ag...@chromium.org>.

Didn't know about npm deprecate. Makes sense to me!

On Tue, Apr 22, 2014 at 7:09 PM, Shazron <sh...@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 <an...@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 <bo...@gmail.com> wrote:
>>
>> > +1
>> >
>> > On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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 <wj...@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 <ag...@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
>> > >> > >>>>>
>> > >> > >>>>
>> > >> > >>>
>> > >> > >>
>> > >> >
>> > >> >
>> > >>
>> >
>>

Re: [DISCUSS] Plugin master branches

Posted by Shazron <sh...@gmail.com>.

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 <an...@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 <bo...@gmail.com> wrote:
>
> > +1
> >
> > On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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 <wj...@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 <ag...@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
> > >> > >>>>>
> > >> > >>>>
> > >> > >>>
> > >> > >>
> > >> >
> > >> >
> > >>
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Anis KADRI <an...@gmail.com>.

+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 <bo...@gmail.com> wrote:

> +1
>
> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@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 <wj...@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 <ag...@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 <pu...@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
> >> > >>>>>
> >> > >>>>
> >> > >>>
> >> > >>
> >> >
> >> >
> >>
>

Re: [DISCUSS] Plugin master branches

Posted by Joe Bowser <bo...@gmail.com>.

+1

On Tue, Apr 22, 2014 at 11:30 AM, Shazron <sh...@gmail.com> wrote:
> +1++
>
>
> On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill <st...@gmail.com>wrote:
>
>> +1!
>>
>>
>> On Tue, Apr 22, 2014 at 10:02 AM, James Jong <wj...@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 <ag...@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 <pu...@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
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> >
>>

Re: [DISCUSS] Plugin master branches

Posted by Shazron <sh...@gmail.com>.

+1++


On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill <st...@gmail.com>wrote:

> +1!
>
>
> On Tue, Apr 22, 2014 at 10:02 AM, James Jong <wj...@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 <ag...@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 <pu...@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
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Steven Gill <st...@gmail.com>.

+1!


On Tue, Apr 22, 2014 at 10:02 AM, James Jong <wj...@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 <ag...@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 <pu...@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
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [DISCUSS] Plugin master branches

Posted by James Jong <wj...@gmail.com>.

+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 <ag...@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 <br...@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 <pu...@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
>>>>> 
>>>> 
>>> 
>>

Re: [DISCUSS] Plugin master branches

Posted by Andrew Grieve <ag...@chromium.org>.

+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 <br...@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 <pu...@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
> > > >
> > >
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Braden Shepherdson <br...@chromium.org>.

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 <br...@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 <pu...@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
> > >
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Bryan Higgins <br...@bryanhiggins.net>.

+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 <ic...@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 <pu...@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
> >
>

Re: [DISCUSS] Plugin master branches

Posted by Ian Clelland <ic...@chromium.org>.

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