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 D768C102C1 for ; Sat, 14 Feb 2015 00:51:58 +0000 (UTC) Received: (qmail 99602 invoked by uid 500); 14 Feb 2015 00:51:52 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 99561 invoked by uid 500); 14 Feb 2015 00:51:52 -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 99537 invoked by uid 99); 14 Feb 2015 00:51:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Feb 2015 00:51:52 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates 209.85.213.169 as permitted sender) Received: from [209.85.213.169] (HELO mail-ig0-f169.google.com) (209.85.213.169) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Feb 2015 00:51:27 +0000 Received: by mail-ig0-f169.google.com with SMTP id hl2so21315959igb.0 for ; Fri, 13 Feb 2015 16:50:39 -0800 (PST) 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:content-type; bh=xJBBrE3lFR54CZi+7cwe2aveI8TRCy1Ed05lBGDfqBs=; b=Xx3Q+bDS99GVXhl5R1gCtKz62KTd8XuHGnR7OtZMhYJQRvemn3NNIgEprYwZmlhEZR HPeamGopfi7hhFLKiyBPyYr/zbXPaxXU+T1i55i0L8m4nInMqMDuWBrRR5Szxuy57vaE 0p8wiG6aWsUQ/fCT7mkdIOpBh3n1Qb69ZDbXg47EPChZ4nd1G7HbrcmKAV/E18rFRy+I KZk8WyoegkFmR5q0MAF7w0FlLAQh8DzDQFUdNXi+PvTQ3IrJtuG3dXbSm5Y9XGRovkPI JmfVqXyq0q2ki1HfDeMOIVwlpUle00uSNG6IN7I1M5wzCpV3MHI9r/Y/EudYPhE6dEF4 8cDQ== 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:content-type; bh=xJBBrE3lFR54CZi+7cwe2aveI8TRCy1Ed05lBGDfqBs=; b=UjSAgqkBHOGNAwniAYQzr6DZ7BhLQxk6TOEGi6xfP/tt9s6W0J0c7QxEq/3tiKfyDs 8Twnvv2fH6F0jxQs4VWQDcR5TQnkorODmDBx8Zhf7WLF0Apt5t2TWWyjw1SghBt1n7dC QW/XAhVz1F6e3GymO1P3R5x+egBYYcXd7kPds= 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:content-type; bh=xJBBrE3lFR54CZi+7cwe2aveI8TRCy1Ed05lBGDfqBs=; b=Ehb4s9C1k4Id04bRtXiVi+EDWp1j2CWZToKigIRR9jLKlGd4CEArlsEE7ZsQvY8KdN Hmr4m9rOc0pXOolzBSPDIsfjZrb/kJ6xvE+kdEy8NdNUZTilUTpHdUhVrOZyzrJFHdK8 kRa7DImfKMVcXCvyJS35jdTH2u/A4gidkVKtbI8f23/5rTAVRHigqsR+0GPcAPd7T8SZ bSs7+a5cR7gOTfpu01iQmW7232UDj3MIDsow3NSUcGZZjp89HlJDrDh3m6Kg1JMNQxl1 7BAsQhjMhNizCgH3SK/FFSDMf99/Hz7Smc2Y0rG2KSiGFtRgzLupU4ZyQCNYv9cnxOPQ rVTw== X-Gm-Message-State: ALoCoQmogzucxt6jfsslqGavt3veVvvaCo2nPblAS0Dh8K0urbInFGARDku2KVZjoeL+0SRqEpty X-Received: by 10.42.152.201 with SMTP id j9mr13018935icw.25.1423875039809; Fri, 13 Feb 2015 16:50:39 -0800 (PST) MIME-Version: 1.0 Sender: agrieve@google.com Received: by 10.36.3.136 with HTTP; Fri, 13 Feb 2015 16:50:19 -0800 (PST) In-Reply-To: <85A3E123BABF314D9D3656D0B4181256448C7A98@FMSMSX103.amr.corp.intel.com> References: <2F4839DC-CD04-419B-A050-1EF61AA831A2@gmail.com> <85A3E123BABF314D9D3656D0B4181256448C5DA1@FMSMSX103.amr.corp.intel.com> <9CDDC605-0C9A-47D5-875F-A8E7D9F5434F@gmail.com> <85A3E123BABF314D9D3656D0B4181256448C7A98@FMSMSX103.amr.corp.intel.com> From: Andrew Grieve Date: Fri, 13 Feb 2015 19:50:19 -0500 X-Google-Sender-Auth: xbt8K3TvxbnAB_bLjo6LsxGZ3Qo Message-ID: Subject: Re: Schedule for npm transition To: dev Content-Type: multipart/alternative; boundary=90e6ba6e889cf3e96c050f01bdf2 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba6e889cf3e96c050f01bdf2 Content-Type: text/plain; charset=UTF-8 I see no reason why we shouldn't post old versions. It's easy to do. On Fri, Feb 13, 2015 at 4:42 PM, Treggiari, Leo wrote: > I have another question which I don't remember being discussed. > > Will older versions of the core plugins be published in NPM? I ask > because existing user projects may reference previous versions of plugins > and may want to be able to continue to fetch them for quite some time. > This is separate from the 'mapper' functionality. E.g. will a user be able > to request cordova-plugin-camera@0.3.4? Note that I see that the current > version is 0.3.5, and I don't actually know how old 0.3.4 is. > > These versioned references can come from a number of places including (as > Andrew pointed out and with one addition from me): > 1. within plugin.xml. > 2. within config.xml (for cordova plugin restore). > 3. within config.xml (or some other source of metadata) for a > 'cloud' Cordova build system. > > Thanks, > Leo > > -----Original Message----- > From: Shazron [mailto:shazron@gmail.com] > Sent: Wednesday, February 11, 2015 3:48 PM > To: dev@cordova.apache.org > Subject: Re: Schedule for npm transition > > I agree with Steve to move forward with this. The package name > rationale was already discussed during the hangout, and we all agreed. > > On Wed, Feb 11, 2015 at 3:43 PM, Steven Gill > wrote: > > Mapper: https://github.com/stevengill/cordova-registry-mapper > > > > Mapper would be a dependency of cordova-lib. We would use it during > cordova > > plugin add/rm to map old id's to new name. > > > > We can look at extending CPR readonly phase but I fear we may have to > deal > > with migrating it to a different provider if want to extend its life. I > am > > not looking forward to dealing with that. > > > > In terms of package-name/package-id, we have been discussing it for > weeks. > > I am not a fan of the flip flopping on this issue and it is seriously > > holding up us moving forward with this. Michal did a great job explaining > > how the mapper could be integrated to handle the workflows. > > > > > > > > On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan > > wrote: > > > >> > >> > >> On 11 Feb 2015, at 15:50, Michal Mocny wrote: > >> > >> Leo, restore will still work. The only information stored in the saves > >>> list is a set of plugin ids (and versions?). Restoring will go through > >>> the > >>> steps Steve outlines above, and either download from CPR or be mapped > >>> automatically to the npm equivalent. After the deprecation cutoff, > >>> plugins > >>> that aren't in the mapper may fail to restore -- so we could improve > the > >>> > >> > >> Any ideas what that mapper will look like? part of CLI, online service? > >> > >> > >> > >> rollout plan by starting to warn users adding plugins that still fetch > >>> from > >>> CPR. > >>> > >>> -Michal > >>> > >>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo < > leo.treggiari@intel.com> > >>> wrote: > >>> > >>> The proposal contains suggestions, alternatives and comments. > >>>> > >>>> > >>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3 > >>>> OXmP-9DpYkcmfs/edit?usp=sharing > >>>> > >>>> When will there be a final version that is the official plan? > >>>> > >>>> One other question: Soon we will have optional 'save' of plugin > metadata > >>>> in config.xml. When CPR is turned off, there will be saved metadata > >>>> which > >>>> is no longer valid - i.e. a restore will fail. This is because the > >>>> 'name' > >>>> used to fetch a plugin (cordova-plugin-device) as well as the location > >>>> will > >>>> change. Is there anything that can be done to mitigate that? Is the > >>>> name > >>>> change really necessary - why can't we stick with the current names? > >>>> > >>>> Thanks, > >>>> Leo > >>>> > >>>> -----Original Message----- > >>>> From: Steven Gill [mailto:stevengill97@gmail.com] > >>>> Sent: Wednesday, February 11, 2015 11:40 AM > >>>> To: dev@cordova.apache.org > >>>> Subject: Re: Schedule for npm transition > >>>> > >>>> Correct! For the first 3 months, all requests will hit CPR first, if > CPR > >>>> fails, we will try to fetch from npm. > >>>> > >>>> If users run "cordova plugin add cordova-plugin-device", it would hit > >>>> CPR, > >>>> fail, go to npm, succeed. > >>>> > >>>> If we use the mapper module, "cordova plugin add > >>>> org.apache.cordova.device" would be converted to > cordova-plugin-device, > >>>> hit > >>>> CPR, fail, go to npm, succeed. > >>>> > >>>> After 3 months, "cordova plugin add cordova-plugin-device" would hit > npm > >>>> first and succeed. > >>>> > >>>> We want to use these 3 months to get our developers to update their > tools > >>>> and use the new names for plugins to install. > >>>> > >>>> On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny > >>>> wrote: > >>>> > >>>> Steve, npm fetch default only affects plugins that use same name in > both > >>>>> places, right? > >>>>> > >>>>> If we create cordova-plugin-device today, and tell users to start > using > >>>>> cordova plugin add cordova-plugin-device, then we will get much user > >>>>> feedback on npm fetching far before May 18th, right? > >>>>> > >>>>> On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill > > >>>>> wrote: > >>>>> > >>>>> We don't have one yet but we should pick dates soon. > >>>>>> > >>>>>> How about: > >>>>>> > >>>>>> CPR Switch to read only: Monday, May 18th > >>>>>> NPM fetch becomes default: Monday, May 18th > >>>>>> CPR offline: Monday, August 17th > >>>>>> > >>>>>> Based on the following proposal: > >>>>>> > >>>>>> > >>>>>> > >>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3 > >>>> OXmP-9DpYkcmfs/edit?usp=sharing > >>>> > >>>>> > >>>>>> - Need to start educating plugin developers to publish to npm as > well > >>>>>> > >>>>> as > >>>> > >>>>> CPR for next three months. (blog post) > >>>>>> - Need to educate users to install plugins via new names (if > >>>>>> > >>>>> package-name > >>>>> > >>>>>> is different than id). Our core plugins are being renamed from > >>>>>> org.apache.cordova.device to cordova-plugin-device > >>>>>> - Inform devs who are working with registry directly to pull plugins > >>>>>> > >>>>> from > >>>> > >>>>> npm instead of CPR. After 3 months, CPR plugins will start to become > >>>>>> > >>>>> out > >>>> > >>>>> of > >>>>> > >>>>>> date compared to npm versions. > >>>>>> > >>>>>> Our next plugins release (after the one currently ongoing) will be > >>>>>> published to npm as well as cpr. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan < > gorkem.ercan@gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>>> Is there a determined calendar for the npm move of the plugins? > >>>>>>> I think the scheduling of the transition is crucial for those who > are > >>>>>>> using the plugin registry directly. > >>>>>>> -- > >>>>>>> Gorkem > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org > >>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org > >>>> For additional commands, e-mail: dev-help@cordova.apache.org > >>>> > >>>> > >>>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org > >> For additional commands, e-mail: dev-help@cordova.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org > For additional commands, e-mail: dev-help@cordova.apache.org > > --90e6ba6e889cf3e96c050f01bdf2--