We don't upgrade plugins as part of platform upgrade anyway, do we? Still, its a good point that we may want to map these to newer versions.
One option could be to leave the old names registered in the plugin registry for a while, and mark deprecated somehow (and perhaps not make them visible from website?), but I think Andrew mentioned that installing a plugin from registry using one canonical name and having its plugin.xml specify a different canonical name meant our tools broke (fail to uninstall?). Perhaps we should just fix that. -Michal On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <mich...@michaelbrooks.ca>wrote: > I prefer the shortened plugin IDs as well. > > Will we want each platform's upgrade script aware of these names in order > to ease the upgrade path from 3.0.0-3.1.0? > > > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <agri...@chromium.org > >wrote: > > > Anis and I discussed a bit on > > https://issues.apache.org/jira/browse/CB-4493 > > > > So I filed https://issues.apache.org/jira/browse/CB-4874 > > > > Wanted to see if anyone could think of what adverse effects this might > have > > before going through with it. > > > > Only thing I can think of is that I'd need to update the <dependency> > tags > > of all plugins (mobile spec and our own). The result of not updating them > > isn't horrible since the dependencies still install via URL. > > > > On a related note - we need remove the url= parameter from the > <dependency> > > so that it looks to the registry. > > > > Once we discuss / take one of these paths, I'd like to do a plugins > release > > so that we can test this flow with RC1. > > >
