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 <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 >
