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
