On Fri, Apr 25, 2014 at 11:42 AM, Ian Clelland <iclell...@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 <agri...@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 <pzal...@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 > > >> <purplecabb...@gmail.com>wrote: > > >> > > >>> > > >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <csantan...@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 <mmo...@chromium.org > > > > >>> > > >>> wrote: > > >>>>> > > >>>>> > > >>>>> Also, it will only "break" new plugin installs. > > >>>>> > > >>>>> > > >>>>> On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland < > > iclell...@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 < > > agri...@chromium.org> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> Didn't know about npm deprecate. Makes sense to me! > > >>>>>>> > > >>>>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <shaz...@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.ka...@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 < > bows...@gmail.com> > > >>>>>> > > >>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> +1 > > >>>>>>>>>> > > >>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <shaz...@gmail.com> > > >>>>>> > > >>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> +1++ > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill < > > >>>>>>> > > >>>>>>> stevengil...@gmail.com > > >>>>>>>>>>> > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> +1! > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Tue, Apr 22, 2014 at 10:02 AM, James Jong < > > >>>>>> > > >>>>>> wjamesj...@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 < > > >>>>>>> > > >>>>>>> agri...@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 < > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> bra...@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 < > > >>>>>>>>>>>> > > >>>>>>>>>>>> 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 < > > >>>>>>>>>>>> > > >>>>>>>>>>>> iclell...@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 < > > >>>>>>>>> > > >>>>>>>>> purplecabb...@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 > > >>>> <csantan...@gmail.com> > > >>> > > >>> > > >> > > > > > > -- > > > Piotr Zalewa > > > Mozilla > > >
