Yeah, but not sure how best to do so. Do we have a way to mark plugins as deprecated? Crazy idea: upload a nearly empty version under the old plugin name that <depends> on the new one, and add a <deprecated> type tag to plugin.xml spec?
-Michal On Fri, Sep 20, 2013 at 6:53 AM, Michael Brooks <mich...@michaelbrooks.ca>wrote: > > > > 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. > > > Good point. > > Regardless, we want to ease the upgrade path of these core plugins. It'll > just annoy users if we change the plugin IDs are hide these changes away in > our documentation. > > Michael > > > On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mmo...@chromium.org> wrote: > > > 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. > > > > > > > > > >
