+1 to giving plugins major version bump +1 to publishing old versions to npm
Short term we can keep dependency tag using plugin ids. Wouldn't it make more sense long term to move those dependencies into package.json file of each plugin? I am going to begin the process of adding package.json to all of our plugins today and will look into publishing older versions to npm. Third-party plugins can either keep their package-id as package-name or rename. It will be up to them. If they keep it, no need to send a PR to mapper module. If they decide on a new package-name, it is probably in their best interest to send a PR. On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana <csantan...@gmail.com> wrote: > Lets consider to take this time and make our plugins 1.0.0 and start > following semver 2.0 more strict. The community is starting to accept that > is ok if the major number is not zero, and a number means something that > can be use in production. > I understand that people might have their own opinion on what is a MAJOR, > meaning an API brake when the plugin is running on the device and the API > of the javascript API to the plugin. > But I want to consider how a plugin is manage in terms of tooling, > declaring and resolving dependencies, plugin.xml schema, > browersify/bootstrapjs, we could say that this consider an API for the > plugin. > Another point is if the plugin are going to change in terms how they are > manage, we can take an opportunity to take the developers attention with > the major version number change to easy distinguish that there something > new going with plugins since 1.0.0 and up. > > On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz <cla...@microsoft.com> wrote: > > > I think the incident over the weekend pointed out that people are in fact > > pinning versions in plugin dependencies to avoid unexpected regressions > or > > in apps due to things like security reviews. (Ex: Each version of a > piece > > of software that is published inside an app needs to go through a legal > > review at some companies.) So, I think it will be critical that people > can > > get back to older versions of plugins beyond the 3 + 6 = 9 month CPR > > window. Big time +1 to back publishing versions npm for that reason > unless > > we intend to keep the CPR around for a long time. We also will want to > > tell plugin authors that they will want to do the same. (Note that I'm > > less worried about IDEs than I am app and plugin authors here.) > > > > > > > > What we're talking about so far has been around changing the behavior of > > cordova-lib over this period. A few questions assuming we go with > having a > > mapper module: > > > > > > > > 1. During and after the transition period, should we recommend that > > 3rd party plugin authors contribute their IDs to the mapper module to > > maintain compat as the CPR shuts down if they want/need to publish to npm > > with a different name? Is there a process we want to setup to make this > > easy? > > > > 2. What about apps using old versions of Cordova that pre-date npm > > support being present? Given it sounds like Nodejitsu will help with any > > migration needed, is there an urgency to shut down the CPR itself > > (regardless of what cordova-lib itself does) in this time window? Or are > we > > simply telling people they have to upgrade to install any new plugins? > > > > > > > > -Chuck > > > > > > > > -----Original Message----- > > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal > > Mocny > > Sent: Tuesday, February 17, 2015 9:32 AM > > To: dev > > Subject: Re: Schedule for npm transition > > > > > > > > FYI since its perhaps relevant to npm transition (from npm weekly notes): > > > > > > > > "We will also be changing the behavior of peerDependencies in npm@3. We > > won't be automatically downloading the peer dependency anymore. Instead, > > we'll warn you if the peer dependency isn't already installed. This > > requires you to resolve peerDependency conflicts yourself, manually, but > in > > the long run this should make it less likely that you'll end up in a > tricky > > spot with your packages' dependencies." > > > > > > > > -Michal > > > > > > > > On Tue, Feb 17, 2015 at 12:13 PM, Andrew Grieve <agri...@chromium.org > > <mailto:agri...@chromium.org>> > > > > wrote: > > > > > > > > > On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny <mmo...@chromium.org > > <mailto:mmo...@chromium.org>> > > > > > wrote: > > > > > > > > > > > On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve > > > > > > <agri...@chromium.org<mailto:agri...@chromium.org>> > > > > > > wrote: > > > > > > > > > > > > > Sorry to be dragging this out, but I think it's important that the > > > > > > > plan here is crystal clear. > > > > > > > > > > > > > > On Wed, Feb 11, 2015 at 4:56 PM, Michal Mocny > > > > > > > <mmo...@chromium.org<mailto:mmo...@chromium.org>> > > > > > > wrote: > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > There is a runtime dependency on plugin ID. It's used when > > > > > > > require()ing other JS modules, and on Android it's used to access > > > > > > > the plugin's > > > > > native > > > > > > > side (pluginManager.getPlugin("ID")). > > > > > > > > > > > > > > We could have a mapper that knows that I type "plugin add "", to > > > > > > > fetch "cordova-plugin-file", but if we also change the plugin ID, > > > > > > > then we'll > > > > > > get > > > > > > > runtime problems. So... if we have a mapper, then no changing > > > > > > > plugin > > > > > IDs. > > > > > > > Correct? > > > > > > > > > > > > > > > > > > > I agree at first, but after sleeping on it, perhaps this is not > > > > > necessarily > > > > > > true. Perhaps changing plugin ID could just be a semver breaking > > change? > > > > > > Then, even if it was installed using old plugin-id and the mapper > > > > > > mapped > > > > > to > > > > > > the npm package-name, any plugin compatible with this MAJOR version > > > > > > of > > > > > the > > > > > > plugin would know to use the new plugin id. > > > > > > > > > > > That'd probably work. In practice I haven't seen plugins pin versions > > > > > within <dependency>, but they probably should. > > > > > > > > > > > > > > > > > > > > > > > > > > > For old versions of the plugin published to npm, we do have to leave > > > > > > the plugin id as-is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okay, so we don't change the plugin ID, just the package name. > > > > > > > - When people use <dependency>, they should still use plugin ID > > > > > > > > > > > > > > > > > > > Nit: why? <dependency> (and config.xml <plugin>) should use the > > > > > > same target as "cordova plugin add", which at this point should > > > > > > change to package-name. If we do leave plugin-id different from > > > > > > package-name, it should only be used internally by plugin authors > > > > > > who depend on other plugins. > > > > > > > > > > > > > > > > "plugin add" can take git URLs, local directory paths. <dependency > > > > > id="" /> is pretty clear that it's an ID, and in this form it doesn't > > > > > specify where to get the plugin from > > > > > > > > > > The logic for dependency in plugman is to: > > > > > 1. Fetch it (e.g. use search paths, or find-by-id from the registry). > > > > > 2. Validate that the plugin.xml we fetched matches the ID from > > > > > <dependency> 3. Install it > > > > > > > > > > I don't think we can do the validation step if we allow package-name > > > > > within <dependency>. Plus, except for core plugins that have a mapper, > > > > > you couldn't do the search-path logic correctly without the plugin ID. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - If they "cordova plugin add", we'll allow them to specify NPM > > > > > > > package name *or* plugin ID. > > > > > > > > > > > > > > > > > > > Possibly only support plugin-id for some deprecation time? (Though > > > > > > if we publish old versions to npm, maybe we just leave it supported > > > > > > + warning > > > > > > always) > > > > > > > > > > > > - We'd use the reverse-mapping so that plugin search path will work > > > > > > if > > > > > they > > > > > > > specify package name. > > > > > > > - E.g. "cordova plugin add cordova-plugin-file", will need to > > > > > > > know to scan search-path directories for "org.apache.cordova.file". > > > > > > > > > > > > > > > > > > > Indeed! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think the different-IDs-than-package-name approach will work, > > > > > > > but I > > > > > > think > > > > > > > it's too much of a hassle to be used by third-party plugins, > > > > > > > because > > > > > it's > > > > > > > more work to have the names be different: > > > > > > > > > > > > > > > > > > > I tend to agree. I think it *could* work, but we should think > > > > > > through if it is necessary. > > > > > > > > > > > > > > > > > > > - If their ID is the same as the package name: > > > > > > > - They fit in more naturally with NPM > > > > > > > - The fetching logic will be faster (since we know we don't > > > > > > > need to check CPR first) > > > > > > > - They don't need to send a pull request and wait for a release > > > > > > > so > > > > > > that > > > > > > > people can install their plugin (mapper) > > > > > > > > > > > > > > If third-parties don't opt into having different package names > > > > > > > from > > > > > > plugin > > > > > > > IDs, then down the road the only plugins that will be in this > > > > > > > state are > > > > > > the > > > > > > > core plugins. Maybe that's fine? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: > > dev-unsubscr...@cordova.apache.org> > > > > > > > > > > > > > For additional commands, e-mail: > > > > > dev-h...@cordova.apache.org<mailto:dev-h...@cordova.apache.org> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Carlos Santana > <csantan...@gmail.com> >
