Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3D3AC11C7B for ; Thu, 24 Apr 2014 20:12:30 +0000 (UTC) Received: (qmail 18324 invoked by uid 500); 24 Apr 2014 20:12:29 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 18295 invoked by uid 500); 24 Apr 2014 20:12:29 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 18281 invoked by uid 99); 24 Apr 2014 20:12:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Apr 2014 20:12:29 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates 209.85.219.48 as permitted sender) Received: from [209.85.219.48] (HELO mail-oa0-f48.google.com) (209.85.219.48) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Apr 2014 20:12:24 +0000 Received: by mail-oa0-f48.google.com with SMTP id m1so3188925oag.21 for ; Thu, 24 Apr 2014 13:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UOEXI85CiLaLG1WNfgnUmikfcN0ogUELGHmrVQrzaIs=; b=E00DSYTvhwEhSuMAlnsEV3UrM7OhG0rhk4xX/Daop0rqlnv6NOtsHrbcwpWSMgufpt uYbtriFJ60QwPS5knusjiaPSmCT/C8kvfwmDsumEZYOTiFX37tGQRwuvHxdQwYhZQt7f c+rI1HLQen8BHvHdzTC8cm1KnI/Yck/jDF1/08xk5PxF8IwJ5EEaV6fbIGcq9GN1hJPT VSUHnrNXGKlOqpIlMKdGox4MvEu2O10Y5DJqcZQrB6lY310WyOyVyEtYtYrnFqQMwum4 A40LjKd5K247nfmFpNpVLiCOZIZ7qHxCCzRB0jy30gkN6AJixQwsZLmR5OzNZBmWNH/H Ks2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UOEXI85CiLaLG1WNfgnUmikfcN0ogUELGHmrVQrzaIs=; b=F3PlgU2oWB9wWnns6YON/BjH0eUpAufLIe0oJx0pNHK25hlAdRzNTxSQdv4ltVIaru ysH0+Z3Mu1lu1H6H0sRx9FfpCvIKn8bVoRb1WIe5VGebfe8sMVjbRrdOMwBunVQkJtmb GzrrD+OJBv5lsqSi4DIDsnx8JHJhPeLwCttts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=UOEXI85CiLaLG1WNfgnUmikfcN0ogUELGHmrVQrzaIs=; b=iu3ScKgEAu1jSnsPiyJZAah7Q1kUUGgczp8AX3UihE2CGw+5bMlm8VchjvhvvOotVZ TnYMx/OBByvLhAvfXkUhMIfsld5UnpKYI6bS00TqVY9kNAeyZFibM7xC/ic0YTluIL7y p1fbc7bSlzjlRQtDd2Zhl2M3hi0AgZzt9OvFZyX9e4osAU3eAX14ELnpdTj48i85txKc CVKt9Q2ZL9nFc7MBMPJmRjRaPxMY5RCGKmIX68H6uAlNfAGmigfws9LAjpVIoXvWhI0h n40wcJ8wAiFYDRO/MEy9LIU68HhRjC3n7IO3wTP3AsiI9xNQvJYC9gFbRm8D5IBSPwil f/tA== X-Gm-Message-State: ALoCoQnD136Kxz3McVnr/roadtXgcDf4gXRBGCorA8e2rUDI80ybFsb1LkCRIc13Lyqt17lyGXl/g4RbsSBRcDDXLrQdQoI4QzAGsov9C9h3uZyNYfhQ/ixce6vFjjnWGdtKzP0GW+AXGRL14L4NBsomqx4u5QPWh5fHs22OufIXzvav6heFGZ3Q4d1oUrQ0pMYcE/ZUfsR65iB8Lh1Gv6/S6QBwfVQ3Ng== X-Received: by 10.182.241.9 with SMTP id we9mr2387755obc.81.1398370323742; Thu, 24 Apr 2014 13:12:03 -0700 (PDT) MIME-Version: 1.0 Sender: agrieve@google.com Received: by 10.182.135.40 with HTTP; Thu, 24 Apr 2014 13:11:43 -0700 (PDT) In-Reply-To: <535950B7.4000002@mozilla.com> References: <3AAB22CF-B009-4977-AE8A-23A10A54984C@gmail.com> <5357d001.c341420a.4ce1.6079@mx.google.com> <535950B7.4000002@mozilla.com> From: Andrew Grieve Date: Thu, 24 Apr 2014 16:11:43 -0400 X-Google-Sender-Auth: _59mxq6SpQjaGUJc9GxkP4XuP_o Message-ID: Subject: Re: [DISCUSS] Plugin master branches To: dev Cc: Braden Shepherdson Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 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 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 >> wrote: >> >>> >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana >>> >>> 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 >>> >>> wrote: >>>>> >>>>> >>>>> Also, it will only "break" new plugin installs. >>>>> >>>>> >>>>> On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland >>>>> >>>>>> 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 >>>>>> wrote: >>>>>> >>>>>>> Didn't know about npm deprecate. Makes sense to me! >>>>>>> >>>>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron 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 >>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron >>>>>> >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> +1++ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill < >>>>>>> >>>>>>> stevengill97@gmail.com >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> +1! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Apr 22, 2014 at 10:02 AM, James Jong < >>>>>> >>>>>> wjamesjong@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 < >>>>>>> >>>>>>> agrieve@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 < >>>>>>>>>>>>> >>>>>>>>>>>>> braden@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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 < >>>>>>>>>>>> >>>>>>>>>>>> bryan@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 < >>>>>>>>>>>> >>>>>>>>>>>> iclelland@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 < >>>>>>>>> >>>>>>>>> purplecabbage@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 >>>> >>> >>> >> > > -- > Piotr Zalewa > Mozilla