[pmwiki-users] recipes on core elements
nospam at eton.ca
Thu Sep 1 22:33:19 CDT 2005
At 2005-09-01 03:19 PM -0400, Radu is rumored to have said:
>However, that requires potentially lots of maintainance. E.g., I modified
>the simple tables function, and now there are changes to it, the recipe
>has to be modified to reflect them. So a recipe creator has to
>continuously monitor pmwiki releases and compare the bits they modify.
>Is that the only way to go, or am I missing something? If that's the only
>way, I'm thinking about somehow automating (at least the checking part of)
>JR? Hagan? Neil? (and others :) How are you dealing with this?
I use a highly sophisticated 6-pronged approach for handling update conflicts:
1) Unless the new PmWiki beta adds a feature I really need, do not install it.
2) Unless the latest version of the Gemini skin (it should be called Hydra,
it has so many versions!) adds a feature I really need, do not install it.
3) Unless a cookbook recipe adds a vital function, do not install it at
all, let alone update it.
4) Whenever I choose to ignore one or more of the previous points, I make a
zip file of the entire installation first and then do the upgrade.
5) I wait to hear complaints about non-working features or stumble upon
6) I find out how to fix the problem on this list.
Note that I have never had to roll back to the zip file. And also note that
I really like the Gemini skin, despite my snide remarks above. And note
that the *only* recipe I have installed is Blocklist2, so there is not much
The fact that my approach has worked so well for me says very little about
my management skills but very much about the robustness and completeness of
PmWiki. Kudos to Patrick!
I am about to embark on an acid test of this approach - upgrading from beta
40 to version 2.0.0 and upgrading Gemini from version 7 to version 36. ;-)
Corporate info at http://www.eton.ca/
Eton Systems, 15 Pinepoint Drive, Nepean, ON, Canada K2H 6B1
Tel: (613) 829-4668
More information about the pmwiki-users