| 2011-01-17 23:03:06 |
Martin Pool |
bug |
|
|
added bug |
| 2011-01-17 23:20:06 |
Martin Pool |
bzr: status |
Confirmed |
In Progress |
|
| 2011-01-17 23:24:20 |
Martin Pool |
description |
At the moment plugins specify the version of the bzrlib api that they need. If we can't satisfy the dependency, then we give a noisy warning and refuse to load it.
But this is in fact rather pedantic: many 2.3 plugins, even if not specifically tested with a later bzr version are still quite likely to work there.
So perhaps we should distinguish:
* api levels at which the plugin will refuse to load and give an up-front warning
* api levels at which the plugin will load and run, but be marked potentially out of date
In the second case, if we get an internal error, we can warn about potentially out of date plugins.
I would be inclined to actually get to this by moving the current declarations into just the "warning" category and then adding a new method that gives a strict dependency. |
At the moment plugins specify the version of the bzrlib api that they need. If we can't satisfy the dependency, then we give a noisy warning and refuse to load it.
But this is in fact rather pedantic: many 2.3 plugins, even if not specifically tested with a later bzr version are still quite likely to work there.
So instead, for plugins that are out of date:
* remember this
* log it
* load them anyhow
If an internal error occurs, we'll mention out-of-date plugins, both on the console and in the apport file.
Then if there is an actual problem, users will get a clue that the plugin is out of date. If there is no actual problem, we won't annoy them.
We can also add a test saying "there are no out-of-date plugins" and that will remind developers to update the check. |
|
| 2011-01-18 00:12:56 |
Martin Pool |
description |
At the moment plugins specify the version of the bzrlib api that they need. If we can't satisfy the dependency, then we give a noisy warning and refuse to load it.
But this is in fact rather pedantic: many 2.3 plugins, even if not specifically tested with a later bzr version are still quite likely to work there.
So instead, for plugins that are out of date:
* remember this
* log it
* load them anyhow
If an internal error occurs, we'll mention out-of-date plugins, both on the console and in the apport file.
Then if there is an actual problem, users will get a clue that the plugin is out of date. If there is no actual problem, we won't annoy them.
We can also add a test saying "there are no out-of-date plugins" and that will remind developers to update the check. |
At the moment plugins specify the version of the bzrlib api that they need. If we can't satisfy the dependency, then we give a noisy warning and refuse to load it.
But this is in fact rather pedantic: many 2.3 plugins, even if not specifically tested with a later bzr version are still quite likely to work there.
So instead, for plugins that are out of date:
* remember this
* log it
* load them anyhow - this may require changing the interface by which they report problems so they call a method rather than raising an exception
* print it in apport crashes
* print it in non-apport crashes
* print it in `bzr plugins`
Then if there is an actual problem, users will get a clue that the plugin is out of date. If there is no actual problem, we won't annoy them.
We can also add a test saying "there are no out-of-date plugins" and that will remind developers to update the check. |
|
| 2011-01-18 01:16:40 |
Martin Pool |
branch linked |
|
lp:~mbp/bzr/704195-plugin-warnings |
|
| 2011-01-18 01:39:03 |
Martin Pool |
summary |
plugins should specify recommended bzrlib version |
don't moan about out-of-date plugins |
|
| 2011-01-18 01:39:17 |
Martin Pool |
description |
At the moment plugins specify the version of the bzrlib api that they need. If we can't satisfy the dependency, then we give a noisy warning and refuse to load it.
But this is in fact rather pedantic: many 2.3 plugins, even if not specifically tested with a later bzr version are still quite likely to work there.
So instead, for plugins that are out of date:
* remember this
* log it
* load them anyhow - this may require changing the interface by which they report problems so they call a method rather than raising an exception
* print it in apport crashes
* print it in non-apport crashes
* print it in `bzr plugins`
Then if there is an actual problem, users will get a clue that the plugin is out of date. If there is no actual problem, we won't annoy them.
We can also add a test saying "there are no out-of-date plugins" and that will remind developers to update the check. |
At the moment plugins specify the version of the bzrlib api that they need. If we can't satisfy the dependency, then we give a noisy warning and refuse to load it.
But this is in fact rather pedantic: many 2.3 plugins, even if not specifically tested with a later bzr version are still quite likely to work there.
So instead, for plugins that are out of date:
* remember this
* log it
* print it in apport crashes
* print it in non-apport crashes
* print it in `bzr plugins`
Then if there is an actual problem, users will get a clue that the plugin is out of date. If there is no actual problem, we won't annoy them.
We can also add a test saying "there are no out-of-date plugins" and that will remind developers to update the check.
|
|
| 2011-01-28 00:59:15 |
Martin Pool |
bzr: status |
In Progress |
Fix Released |
|
