[wp-hackers] Making Updates Friendlier?

[Doug Stewart]

Sorry for the top post -- iPhone makes bottom-posting a real pain.

How about building an easy "back out" procedure into the core upgrade?
Back up the db, copy all core files to a safe tmp and then upgrade.
Things not working? Create a dialog like Apple's crash reporter and
have the users send feedback to WP along with a generated list of
plugins and their versions. Maybe even have the crash receiver be able
to respond with "version 3.14 of Plugin X us known not to work with
the newest WP. Please contact the author (insert author contact from
plugin description here)."

Remove as many speesbumps as possible. And yes, absolutely color code
the alerts. *grin*

-Doug

On Tuesday, September 8, 2009, Andy Skelton <skeltoac at gmail.com> wrote:
> On Tue, Sep 8, 2009 at 3:03 PM, Dougal Campbell<dougal at gunters.org> wrote:
>> From their perspective, it's simple: the
>> plugin worked before the upgrade, and it was broken after. Therefore, the WP
>> upgrade "broke" the plugin. You'll probably never convince them to look at
>> it any other way. But I have to wonder if we can't try...something. I'm not
>> sure what. But since this seems to be a large source of the FUD concerning
>> upgrades, it certainly seems worth discussing it and kicking around some
>> ideas on how to address it.
>
> I had a thought. The only way to save the user from himself--short of
> educating him--is to automate. Automating a safe upgrade begins with
> knowing how to do it manually. Before upgrading a site you must see
> that it works as-is. Then you must upgrade the site (preferably a
> copy) and see whether it works. The baseline for what's working is
> whatever passes your test. Or a test suite. Uh oh, unit tests.
>
> So if you are to really fix the problem of broken-after-upgrade you
> must have tests to run and compare before and after, a copy of the
> site, and something smart to do when a test fails. Code not covered by
> tests (plugins and themes) would be troublesome but not fatal; process
> of elimination is valid intelligence gathering. Tests for plugins and
> themes should be supplied by their authors, which is a cultural shift
> that will meet resistance proportional to the size of the Extend
> repositories.
>
> The size of the WordPress repository is also daunting but it needn't
> all have test cases from the start. It could be begun with just one
> simple test case and grow from there: does index.php produce 200
> OK...</head>?
>
> The other way would be to toss the old plugin and theme systems and
> write new ones that encapsulated non-core code and enforced nice play.
> That would be great for the ivory tower set but not so much for folks
> entrenched like most of us are.
>
> Andy
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

-- 
-Doug