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