[wp-hackers] Plugin zip problem on wordpress.org

[Michael D Adams]

> I think the consensus from people who responded is that adding the  
> option to specify a subdirectory would be useful. It's backwards  
> compatible, I don't see any down side nor have I noticed any  
> objections.

Well - there's always a down side:  figuring out how it should work,  
time in making it happen, documenting it, etc.  More importantly, one  
goal of the WordPress Plugin Directory is to make downloading and  
installing experience for all plugins to be as consistent as possible  
for the user.  How do we ensure that experience is the same for  
plugins using the subdirectory feature and for those that don't?

There are however compelling reasons to offer such a feature.  So  
let's talk about how it should happen.


Situation:

I have a plugin called Wonder Plugin hosted at http://svn.wp- 
plugins.org/wonder-plugin/.  Suppose I have files that look like this:

/wonder-plugins/tags/2.1/readme.txt
/wonder-plugins/tags/2.1/tests.php
/wonder-plugins/tags/2.1/release/wonder.php

And a readme.txt file *in trunk/* with the following line:

Stable Tag: 2.1/release


Proposal:

The Plugin directory will package the zip file from the release/  
subdirectory of the 2.1 tag rather than zipping up everything.

The zip file will contain the readme.txt file as well, even though  
the readme.txt file is not in the release/ directory.  (If there is  
another readme.txt file in the release/ directory it will get  
*overwritten*).

The zip file will contain all of those files (release/* and  
readme.txt) wrapped in a directory called wonder-plugin/.  So the  
contents of the zip will look like:

wonder-plugin/readme.txt
wonder-plugin/wonder.php

The zip file will be named wonder-plugin.zip.

Zip files from other tags (downloaded from the "other versions" link,  
e.g. http://wordpress.org/extend/plugins/podpress/download/) will  
contain the *entire* SVN tree.  Why?  We determine the "packaging  
subdirectory" from the readme file in trunk/.  The directory  
structure can change between tags, so we can't know from trunk/ 
readme.txt what the right thing to do is for any tag but the stable  
one.  We could parse each tag's readme.txt, but I'm not convinced  
that's useful for plugin authors or users.  This is *inconsistent*.   
Is that bad?

If the plugin had specified Stable Tag: trunk/release, everything  
above would apply with the trunk/ dir taken to be the stabel "tag"  
dir. (Stable Tag: trunk is equivalent to not including a Stable Tag  
field.  Including it is best practice.)

If the plugin had no subdirectory in its Stable Tag field, the entire  
tag directory is packaged in the zip (this is what happens now).

Thoughts?

Mike