I would agree that we should change plugin ID as well as package name, but I don't think that affects the results.
All 3 of those use cases you mentioned I think are addressed equivalently. Whether the plugin is added as a dependency, with save/restore, or explicitly from the command line, cordova-lib would first check if there is a mapping from old ID -> new package name, or use what's given verbatim. So the only concern is with third party plugin authors who chose to rename plugins, and already have dependants, and don't register a mapping with us. I believe the only real question is: do we prefer a minimally easier transition by leaving all names as they are, or do we prefer to have package names on npm that don't look out of place. I think any argument that there is a technical preference for one way over the other hasn't really held up (but now would be a great time to mention if that isn't true). (Note: choosing leaving names as they are still only guarantees core plugins do this, 3rd party authors may not re-publish at all, or rename however they want) -Michal On Wed, Feb 11, 2015 at 4:07 PM, Andrew Grieve <agri...@chromium.org> wrote: > Going to try and summarize my concerns with the proposal here: > > On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill <stevengil...@gmail.com> > wrote: > > > 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. > > > > CPR doesn't allow non-reverse dns names. There'd be no reason to check it > unless the name had at least 2 periods in it. > > If we're not using package names to detect which registry to use, I don't > actually see any benefit in changing names. > > > > > > 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. > > > > While this works fine for our modules, I don't think it'll work well for > others'. Three use-cases for them: > 1. <dependency> within plugin.xml. > 2. <plugin> within config.xml (for cordova plugin restore). > 3. cordova plugin add FOO > > All three would be solved if we enforce that packageName == pluginId. > > I think we should either: > - publish under npm under our existing IDs > or: > - publish under npm under cordova-plugin-FOO, and change plugin IDs to be > cordova-plugin-FOO > > > > > > > > > > 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 <mmo...@chromium.org> > > 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 <stevengil...@gmail.com> > > > 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/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-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.er...@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-unsubscr...@cordova.apache.org > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > > > > > > > >
