[wp-hackers] support for custoim post types + custom feilds

[Curtis McHale]

There should also be an easy mechanism of transferring plugin 
ownership/responsibility to a new person. I know this has been discussed 
in previous threads so...

There should be a way for you to remove a plugin from the repo as well. 
As you've stated people bug you about a plugin that you haven't 
supported in years. If it's still in the repo I'd ask why? It really 
should be removed and it should be easy for a plugin author to remove it.

On top of clean uninstall it should offer to give you a downloadable 
.zip of the data before deletion. If you're removing it I'm guessing you 
don't need it but having it as a standard option is a good idea IMO.

With version compatibility I think WP should recognize if a plugin is 
not listed as 3.0 (or whatever) compatible and warn you of that.

eric at eamann.com wrote:
> So let's put together a checklist.  Quite a few plug-in developers follow this
> mailing list, so if we build a checklist and mark it as complete (perhaps even
> add a page to the plug-in development section of the codex?) then it gives us
> the foundation for a standard.
>   
> So far you've covered a few points:
> 1) Clean install/uninstall (document what options and db tables are created -
> remove both on uninstall).
> 2) Version compatibility (the WP site already has a framework in place for this,
> but it's not as explicit as many of us would like - maybe set a few standard
> tests and checks to verify it works with each version?  Like a documented list
> of which WP functions the plug-in depends on which can easily be compared to the
> list of out-dated/deprecated/unsupported functions in core).
>   
> Some things I'd like to see are explicit guarantees of support.  When is the
> plug-in released?  Who is the individual responsible for coordinating support if
> something breaks?  How long does the author intend to support the plug-in?
>   There are people still using a plug-in I wrote years ago that I've stated many
> times I no longer support (the functionality it provides is now a part of core
> and redundant), but I still get the occasional "X broke when I did Y" email.
>   
> If we put together a standard, then it's a quick matter for plug-in authors to
> say "My plug-in meets the ---- standard as of 6/21/2010" and offer that
> additional level of comfort for end-users.  It also makes it easy to audit that
> statement if, for example, an author failed to actually test against a new
> release.
>
>   
>
> On June 21, 2010 at 4:46 PM Curtis McHale<curtis at curtismchale.ca>  wrote:
>
>    
>> Yeah that's probably pretty close. Like I said if there was a more
>> robust system for plugins to get into the repository or a checklist that
>> plugins had to match up against I believe that some of the issues would
>> not be present.
>>
>> scribu wrote:
>>      
>>> Summarizing what I've read so far:
>>>
>>> Plugins are for hobbyists. Serious sites don't trust them.
>>>
>>> Themes are ok, because [unlike plugins?!] their code can be reviewed.
>>>
>>>
>>>        
>> --
>> Curtis McHale
>>
>> 604.751.3482
>> http://curtismchale.ca
>> http://twitter.com/curtismchale
>> http://ca.linkedin.com/in/curtismchale
>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>      
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>    

-- 
Curtis McHale

604.751.3482
http://curtismchale.ca
http://twitter.com/curtismchale
http://ca.linkedin.com/in/curtismchale