Changes between Version 34 and Version 35 of PadrePluginCookbookRecipie05


Ignore:
Timestamp:
08/26/11 19:26:40 (3 years ago)
Author:
bowtie
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PadrePluginCookbookRecipie05

    v34 v35  
    121121        2, it appairs to me you only need, 'Padre::Plugin' => 0.nn, 
    122122Alias 
    123     You need to declare everything you use 
     123        You need to declare everything you use 
    124124        So if you use Padre::Logger, you need to declare that 
    125125        If you do $plugin->main->some_method you need to do Padre::Wx::Main 
     
    135135        This is about failure modes 
    136136        We have a choice about how we want plugins to fail 
    137         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 
     137        1, Always have every plugin load, wait for each one to do something illegal in Padre and blow up, 
     138        leaving it half-loaded or in some unknown state and maybe crashing Padre 
    138139        2. Disable some plugins due to "compatibility" which really will still work, just in case one was using the specific part you changed 
    139         In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disasterous 
    140         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 
     140        In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disastrous 
     141        In the second case, plugin authors need to check they still work, bump the plugin's dependency hash past the change, 
     142        and do a simple incremental release 
    141143        The second is much more responsible, and much safer when there's no firewall between the plugins and the core 
    142144        Firefox doesn't even give THAT much leeway 
     
    145147        Which is more cpan friendly 
    146148bowtie 
    147         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? 
     149        ok, so the the the modules version will be that of the Padre version it was created against, 
     150        hence all module version numbers should be the same? 
    148151Alias 
    149152        Usually yes 
     
    160163        Well, it IS theoretically possible 
    161164bowtie 
    162     so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :) 
     165        so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :) 
    163166Alias 
    164167        api version is the same 
     
    177180        A bit like Padre::Task 2.0 
    178181bowtie 
    179         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 
     182        on reflection I got that, but I don't know what the padre version was then, 
     183        and if I use that version will a plugin be back compatable 
    180184Alias 
    181185        You don't have to