Changes between Version 33 and Version 34 of PadrePluginCookbookRecipie05

Timestamp:

08/26/11 19:15:36 (21 months ago)

Author:

bowtie

Comment:

--

PadrePluginCookbookRecipie05

@@ -116 +116 @@
 * draft needs tiding up
 {{{#!text
-12:05 bowtie     Alias_, Padre::Plugin POD, padre_interfaces, lists Padre modules and version numbers.
-12:05 bowtie     1, is it upto date
-12:05 bowtie     2, it appairs to me you only need, 'Padre::Plugin' => 0.nn,
-12:05 Alias_     You need to declare everything you use
-12:05 Alias_     So if you use Padre::Logger, you need to declare that
-12:05 Alias_     If you do $plugin->main->some_method you need to do Padre::Wx::Main
-12:05 Alias_     etc
-12:06 Alias_     You declare the parts of Padre that you use
-12:06 Alias_     So when we break compatibility in one part of Padre, ALL the plugins that use it aren't loaded, but ONLY the plugins that use it are disabled
-12:07 bowtie     Alias_, but plugins still work and don't through any errors or warnings at present
-12:07 Alias_     You THINK they work
-12:07 Alias_     They MIGHT work
-12:07 Alias_     But you can't know that
-12:07 Alias_     This is about failure modes
-12:07 Alias_     We have a choice about how we want plugins to fail
-12:08 Alias_     1. Always have every plugin load, wait for each one to do something illegal in Padre and blow up, leaving it half-loaded or in some unknown state and maybe crashing PAdre
-12:08 Alias_     2. Disable some plugins due to "compatibility" which really will still work, just in case one was using the specific part you changed
-12:09 Alias_     In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disasterous
-12:09 Alias_     In the second case, plugin authors need to check they still work, bump the plugin's dependency hash past the change, and do a simple incremental release
-12:10 Alias_     The second is much more responsible, and much safer when there's no firewall between the plugins and the core
-12:10 Alias_     Firefox doesn't even give THAT much leeway
-12:10 Alias_     Every plugin is automatically disabled, until they SPECIFICALLY test they still work
-12:10 Alias_     We are at least doing piece-meal disable on a per class basis
-12:10 Alias_     Which is more cpan friendly
-12:11 bowtie     Alias_, ok, so the the the modules version will be that of the Padre version it was created against, hence all module version numbers should be the same?
-12:12 Alias_     Usually yes
-12:12 Alias_     But someone might have checked that one specific class hasn't changed in the place we care about further back
-12:13 Alias_     Or one plugin might depend on another plugin
-12:13 Alias_     And so on
-12:13 bowtie     Alias_, I will add this to cookbook wiki then, ok
-12:13 Alias_     But USUALLY they will all be the same
-12:13 bowtie     Alias_, the POD shows diffrent versions
-12:13 Alias_     Well, it IS theoretically possible
-12:15 bowtie     Alias_, so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :)
-12:15 Alias_     api version is the same
-12:15 Alias_     Padre::Plugin is just another class that the plugin "depends on"
-12:16 bowtie     Alias_, from POD, Padre::Plugin - Padre plug-in API 2.2
-12:16 Alias_     oh, that
-12:16 Alias_     That's mostly just a way of mentally marking time
-12:16 Alias_     It's not really any kind of official thing
-12:16 bowtie     Alias_, yes it's confuses me
-12:17 Alias_     Basically it just says "We've completely rewritten it twice, and made some big additions twice since then"
-12:17 Alias_     It's for humans, not machines
-12:18 Alias_     A bit like Padre::Task 2.0
-12:18 bowtie     Alias_, on reflection I got that, but I don't know what the padre version was then, and if I use that version will a plugin be back compatable
-12:19 Alias_     You don't have to
-12:19 Alias_     You just say the most recent version of Padre you are SURE that the plugin works with
-12:19 Alias_     And Padre itself tracks compatibility for you
-12:19 bowtie     Alias_, I developed against :)
-12:20 Alias_     our $COMPATIBLE = '0.43';
-12:20 bowtie     oops i -> ie
-12:20 Alias_     See that?
-12:20 Alias_     That's in Padre::Plugin
-12:20 Alias_     So at a guess, the last time I broke compatibility for ALL plugins was likely 2.0 landing
-12:20 bowtie     Alias_, POD shows 0.29
-12:20 Alias_     Which means 2.0 probably arrived around about 0.43
-12:23 bowtie     Alias_, ca I do perl dev -t Class::Name, Class::Name2
-12:23 Alias_     Nope
-12:23 bowtie     only one :(
-12:25 bowtie     Alias_, all modules used by a Plugin that are not part of Padre core should be in sub plugin_disable
-12:26 bowtie     even if required
-12:26 Alias_     All plugin modules should be
-12:26 Alias_     Don't unload third party modules
-12:26 Alias_     You have no idea if anything else needs them
-12:27 bowtie     Alias_, you mean Mouse for example
-12:27 Alias_     right
-12:27 Alias_     Only unload the plugin's own modules
-12:29 bowtie     Alias_, ok if a Plugin over loads sub plugin_icon
-12:30 * azawawi  home &
-12:35 Alias_     You can overload pretty much anything you like
-12:36 bowtie     Alias_, you are so happy it must be your un-Birthday again :), thanks
+bowtie
+        Padre::Plugin POD, padre_interfaces, lists Padre modules and version numbers.
+        1, is it upto date
+        2, it appairs to me you only need, 'Padre::Plugin' => 0.nn,
+Alias
+    You need to declare everything you use
+        So if you use Padre::Logger, you need to declare that
+        If you do $plugin->main->some_method you need to do Padre::Wx::Main
+        etc
+        You declare the parts of Padre that you use
+        So when we break compatibility in one part of Padre, ALL the plugins that use it aren't loaded, but ONLY the plugins that use it are disabled
+bowtie
+        but plugins still work and don't through any errors or warnings at present
+Alias
+        You THINK they work
+        They MIGHT work
+        But you can't know that
+        This is about failure modes
+        We have a choice about how we want plugins to fail
+        1. Always have every plugin load, wait for each one to do something illegal in Padre and blow up, leaving it half-loaded or in some unknown state and maybe crashing PAdre
+        2. Disable some plugins due to "compatibility" which really will still work, just in case one was using the specific part you changed
+        In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disasterous
+        In the second case, plugin authors need to check they still work, bump the plugin's dependency hash past the change, and do a simple incremental release
+        The second is much more responsible, and much safer when there's no firewall between the plugins and the core
+        Firefox doesn't even give THAT much leeway
+        Every plugin is automatically disabled, until they SPECIFICALLY test they still work
+        We are at least doing piece-meal disable on a per class basis
+        Which is more cpan friendly
+bowtie
+        ok, so the the the modules version will be that of the Padre version it was created against, hence all module version numbers should be the same?
+Alias
+        Usually yes
+        But someone might have checked that one specific class hasn't changed in the place we care about further back
+        Or one plugin might depend on another plugin
+        And so on
+bowtie
+        I will add this to cookbook wiki then, ok
+Alias
+        But USUALLY they will all be the same
+bowtie
+        the POD shows diffrent versions
+Alias
+        Well, it IS theoretically possible
+bowtie
+    so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :)
+Alias
+        api version is the same
+        Padre::Plugin is just another class that the plugin "depends on"
+bowtie
+        from POD, Padre::Plugin - Padre plug-in API 2.2
+Alias
+        oh, that
+        That's mostly just a way of mentally marking time
+        It's not really any kind of official thing
+bowtie
+        yes it's confuses me
+Alias
+        Basically it just says "We've completely rewritten it twice, and made some big additions twice since then"
+        It's for humans, not machines
+        A bit like Padre::Task 2.0
+bowtie
+        on reflection I got that, but I don't know what the padre version was then, and if I use that version will a plugin be back compatable
+Alias
+        You don't have to
+        You just say the most recent version of Padre you are SURE that the plugin works with
+        And Padre itself tracks compatibility for you
+bowtie
+        ie developed against :)
+Alias
+        our $COMPATIBLE = '0.43';
+        That's in Padre::Plugin
+        So at a guess, the last time I broke compatibility for ALL plugins was likely 2.0 landing
+bowtie
+        POD shows 0.29
+Alias
+        Which means 2.0 probably arrived around about 0.43
+bowtie
+        can I do perl dev -t Class::Name, Class::Name2
+Alias
+        Nope
+bowtie
+        only one :(
+        all modules used by a Plugin that are not part of Padre core should be in sub plugin_disable
+        even if required
+Alias
+        All plugin modules should be
+        Don't unload third party modules
+        You have no idea if anything else needs them
+bowtie
+        you mean Mouse for example
+Alias
+        right
+        Only unload the plugin's own modules
+bowtie
+        ok if a Plugin over loads sub plugin_icon
+Alias
+        You can overload pretty much anything you like
+bowtie
+        you are so happy it must be your un-Birthday again :), thanks
 }}}