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 <[email protected]> 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 <[email protected]> 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 > >> <[email protected]>wrote: > >> > >>> > >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <[email protected]> > >>> > >>> 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/[email protected]"; > >>> > >>> > >>> Yes, this. > >>> > >>>> > >>>> --Carlos > >>>> > >>>> > >>>> > >>>>> On Wed, Apr 23, 2014 at 9:30 AM, Michal Mocny <[email protected]> > >>> > >>> wrote: > >>>>> > >>>>> > >>>>> Also, it will only "break" new plugin installs. > >>>>> > >>>>> > >>>>> On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland < > [email protected] > >>>>>> > >>>>>> 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 < > [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> Didn't know about npm deprecate. Makes sense to me! > >>>>>>> > >>>>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <[email protected]> > 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 < > [email protected]> > >>>>>>>> > >>>>>>>> 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 <[email protected]> > >>>>>> > >>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> +1 > >>>>>>>>>> > >>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <[email protected]> > >>>>>> > >>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> +1++ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill < > >>>>>>> > >>>>>>> [email protected] > >>>>>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> +1! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Tue, Apr 22, 2014 at 10:02 AM, James Jong < > >>>>>> > >>>>>> [email protected] > >>>>>>>> > >>>>>>>> > >>>>>>>>>> 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 < > >>>>>>> > >>>>>>> [email protected]> > >>>>>>>>>>>> > >>>>>>>>>>>> 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 < > >>>>>>>>>>>>> > >>>>>>>>>>>>> [email protected]>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 < > >>>>>>>>>>>> > >>>>>>>>>>>> [email protected] > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>> > >>>>>>>>>>>> [email protected] > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> 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 < > >>>>>>>>> > >>>>>>>>> [email protected]> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 > >>>> <[email protected]> > >>> > >>> > >> > > > > -- > > Piotr Zalewa > > Mozilla >
