The zip contains the following directory structure: /wp-mail-smtp/ /wp-mail-smtp/readme.txt /wp-mail-smtp/screenshot.png /wp-mail-smtp/wp-mail-smtp/ /wp-mail-smtp/wp-mail-smtp/wp_mail_smtp.php
The correct structure is just: /wp-mail-smtp/ /wp-mail-smtp/wp_mail_smtp.php
My readme in trunk points to the stable tag as 0.4, the dir structure there is tags/0.4/readme.txt tags/0.4/screenshot.png tags/0.4/wp-mail-smtp/ tags/0.4/wp-mail-smtp/wp_mail_smtp.php
Anyone got any clues? Is this a bug? I notice that plugins that haven't been updated for a while (Akismet for example) are fine. Could it be a recent change?
On 10/7/07, Callum Macdonald <lists.automattic....@callum-macdonald.com> wrote:
> ... > Anyone got any clues? Is this a bug? I notice that plugins that haven't > been updated for a while (Akismet for example) are fine. Could it be a > recent change?
I'm not seeing it on mine, but perhaps this may help narrow it down:
We updated one of our plugins last week (I believe it was Friday, Oct. 5th). When I download the zip file, it has the correct structure, the times for all the files inside are set to 2007/10/06 8:10am.
All that to say that if your issue was caused by a recent change in the packaging routine (and if it would affect all plugins), it must have been a very recent change, since it didn't seem to affect mine. _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
You have a "wp-mail-smtp" folder in your "0.4" folder, so therefore it's making a folder in the ZIP.
The ZIP script automatically puts all of your plugin's files in a folder, so there's no need to make a folder of your own. Just put everything in the root.
On 10/7/07, Callum Macdonald <lists.automattic....@callum-macdonald.com> wrote:
> The zip contains the following directory structure: > /wp-mail-smtp/ > /wp-mail-smtp/readme.txt > /wp-mail-smtp/screenshot.png > /wp-mail-smtp/wp-mail-smtp/ > /wp-mail-smtp/wp-mail-smtp/wp_mail_smtp.php
> The correct structure is just: > /wp-mail-smtp/ > /wp-mail-smtp/wp_mail_smtp.php
> My readme in trunk points to the stable tag as 0.4, the dir structure > there is > tags/0.4/readme.txt > tags/0.4/screenshot.png > tags/0.4/wp-mail-smtp/ > tags/0.4/wp-mail-smtp/wp_mail_smtp.php
> Anyone got any clues? Is this a bug? I notice that plugins that haven't > been updated for a while (Akismet for example) are fine. Could it be a > recent change?
Viper007Bond wrote: > You have a "wp-mail-smtp" folder in your "0.4" folder, so therefore it's > making a folder in the ZIP.
> The ZIP script automatically puts all of your plugin's files in a folder, so > there's no need to make a folder of your own. Just put everything in the > root.
> On 10/7/07, Callum Macdonald <lists.automattic....@callum-macdonald.com> > wrote:
>> The zip contains the following directory structure: >> /wp-mail-smtp/ >> /wp-mail-smtp/readme.txt >> /wp-mail-smtp/screenshot.png >> /wp-mail-smtp/wp-mail-smtp/ >> /wp-mail-smtp/wp-mail-smtp/wp_mail_smtp.php
>> The correct structure is just: >> /wp-mail-smtp/ >> /wp-mail-smtp/wp_mail_smtp.php
>> My readme in trunk points to the stable tag as 0.4, the dir structure >> there is >> tags/0.4/readme.txt >> tags/0.4/screenshot.png >> tags/0.4/wp-mail-smtp/ >> tags/0.4/wp-mail-smtp/wp_mail_smtp.php
>> Anyone got any clues? Is this a bug? I notice that plugins that haven't >> been updated for a while (Akismet for example) are fine. Could it be a >> recent change?
> Is that a new thing? I thought previously it worked in that format. I'll > change it on svn anyway.
> Cheers - Callum.
> Viper007Bond wrote: > > You have a "wp-mail-smtp" folder in your "0.4" folder, so therefore it's > > making a folder in the ZIP.
> > The ZIP script automatically puts all of your plugin's files in a > folder, so > > there's no need to make a folder of your own. Just put everything in the > > root.
> > On 10/7/07, Callum Macdonald <lists.automattic....@callum-macdonald.com> > > wrote:
> >> The zip contains the following directory structure: > >> /wp-mail-smtp/ > >> /wp-mail-smtp/readme.txt > >> /wp-mail-smtp/screenshot.png > >> /wp-mail-smtp/wp-mail-smtp/ > >> /wp-mail-smtp/wp-mail-smtp/wp_mail_smtp.php
> >> The correct structure is just: > >> /wp-mail-smtp/ > >> /wp-mail-smtp/wp_mail_smtp.php
> >> My readme in trunk points to the stable tag as 0.4, the dir structure > >> there is > >> tags/0.4/readme.txt > >> tags/0.4/screenshot.png > >> tags/0.4/wp-mail-smtp/ > >> tags/0.4/wp-mail-smtp/wp_mail_smtp.php
> >> Anyone got any clues? Is this a bug? I notice that plugins that haven't > >> been updated for a while (Akismet for example) are fine. Could it be a > >> recent change?
> The zip contains the following directory structure: > /wp-mail-smtp/ > /wp-mail-smtp/readme.txt > /wp-mail-smtp/screenshot.png > /wp-mail-smtp/wp-mail-smtp/ > /wp-mail-smtp/wp-mail-smtp/wp_mail_smtp.php
> The correct structure is just: > /wp-mail-smtp/ > /wp-mail-smtp/wp_mail_smtp.php
> My readme in trunk points to the stable tag as 0.4, the dir structure > there is > tags/0.4/readme.txt > tags/0.4/screenshot.png > tags/0.4/wp-mail-smtp/ > tags/0.4/wp-mail-smtp/wp_mail_smtp.php
> Anyone got any clues? Is this a bug? I notice that plugins that haven't > been updated for a while (Akismet for example) are fine. Could it be a > recent change?
On 10/9/07, Michael D Adams <m...@blogwaffe.com> wrote:
This is the intended behavior. All download zips get wrapped in a directory (in your case wp-mail-smtp) for consistency. There is no need to put your files in subdirectory. See http://wordpress.org/extend/plugins/about/faq/
PS: Sorry - I never got these emails from the wp-hackers list (something must have been wrong with my mail server or theirs), so I couldn't reply on list. _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
> This is the intended behavior. All download zips get wrapped in a > directory (in your case wp-mail-smtp) for consistency. There is no > need to put your files in subdirectory. See > http://wordpress.org/extend/plugins/about/faq/
It's a great big PITA if you have files you don't want to distribute, though. It would make a lot more sense for only files in the appropriately-named subdirectory to get packaged. Case in point, I have a whole series of tests that belong in the repository, and are tied to the release version, but shouldn't be distributed in the tarball. I've had to resort to tagging two "releases", one real one, and one exclusively for the benefit of the packager.
Similarly, the screenshots don't need to be in the release zip (especially since the images can't have reasonable names), but the current packaging scheme *forces* the image files to be included if you want the screenshots to show up on the site.
I really think that the current packaging logic is at best a misfeature, if not a bug. :/
> It's a great big PITA if you have files you don't want to distribute, > though.
What if the "Stable Tag" field in the readme could specify a directory instead of just a tag name?
Stable Tag: 2.1/sub-directory
would result in tags/2.1/sub-directory/ being packaged as the download zip. For the "Other Versions" section of the plugin directory, we'd probably still package the whole "root" directory (tags/2.1/) because we can't know if all tags have the same directory structure.
Travis Snoozy wrote: > It's a great big PITA if you have files you don't want to distribute, > though. It would make a lot more sense for only files in the > appropriately-named subdirectory to get packaged. Case in point, I have > a whole series of tests that belong in the repository, and are tied to > the release version, but shouldn't be distributed in the tarball. I've > had to resort to tagging two "releases", one real one, and one > exclusively for the benefit of the packager.
Could you provide examples of other automated packaging systems that behave that way? It was my impression that tagging different versions for different audiences is a common practice.
> Similarly, the screenshots don't need to be in the release zip > (especially since the images can't have reasonable names), but the > current packaging scheme *forces* the image files to be included if you > want the screenshots to show up on the site.
Just to clarify, what's your logical reasoning for not including screenshots in the release zip?
> On Oct 9, 2007, at 12:42 PM, Travis Snoozy wrote: >> It's a great big PITA if you have files you don't want to distribute, >> though.
> What if the "Stable Tag" field in the readme could specify a directory > instead of just a tag name?
> Stable Tag: 2.1/sub-directory
> would result in tags/2.1/sub-directory/ being packaged as the download > zip. For the "Other Versions" section of the plugin directory, we'd > probably still package the whole "root" directory (tags/2.1/) because > we can't know if all tags have the same directory structure.
> Would that help with these issues? Thoughts?
Besides the FAQ saying:
> Can't I put my files in a subdirectory of |trunk/|?
> You can, but it's silly
and I don't agree that it's silly, it would at least help me. Especially as the dir assigned to me is post-notification, and the plugin works in post_notification (underline!), ever since. I requested post_notification and got post-notification, but didn't bother as by that time everything was working fine and after that, I didn't get any replies to my mail any more.
On Tue, 09 Oct 2007 17:45:40 -0400, Keith Constable
<kccric...@gmail.com> wrote: > Travis Snoozy wrote: > > It's a great big PITA if you have files you don't want to > > distribute, though. It would make a lot more sense for only files > > in the appropriately-named subdirectory to get packaged. Case in > > point, I have a whole series of tests that belong in the > > repository, and are tied to the release version, but shouldn't be > > distributed in the tarball. I've had to resort to tagging two > > "releases", one real one, and one exclusively for the benefit of > > the packager.
> Could you provide examples of other automated packaging systems that > behave that way? It was my impression that tagging different versions > for different audiences is a common practice.
Define "automated packaging system". The closest thing I can think of is GNU autotools (info automake), which makes generally-correct guesses, but also lets you tune exactly what does and does not go in the release tarball. In any case, what is in SVN should *always* be construed as the developer version -- the user-version that gets released is almost always a subset of the dev version (generated from the dev version, e.g., with make dist). One should never have to tag the same thing twice in the repo to do a single release.
> > Similarly, the screenshots don't need to be in the release zip > > (especially since the images can't have reasonable names), but the > > current packaging scheme *forces* the image files to be included if > > you want the screenshots to show up on the site.
> Just to clarify, what's your logical reasoning for not including > screenshots in the release zip?
For In Series 3.0.7 procured from WordPress.com...
Size of the zipfile: 272KiB Size of just the unzipped PNG files: 264KiB Size of just the PNG files zipped: 249KiB Size of just the unzipped source: 104KiB Size of just the source files zipped: 24KiB
Now, when the zipped screenshots are twice the size of the uncompressed code, and *ten* times the size of the compressed code, I have to wonder: are people downloading my plugin, or the screenshots? If people wanted to see the screenshots, they can go to the screenshots page either off WordPress.com, or off the plugin's home page. In any case, those screenshots aren't used in the final installation (which is supposed to just be "unzip this in your plugins directory"), so the most likely thing that will happen is (1) they'll be immediately deleted, or (2) they'll sit around and be useless until an upgrade comes along. It's an utter waste of bandwidth and space.
I might want a dozen screenshots in the future. Or two dozen. But that will bloat my release, so I'm effectively limited on what I can show off (20 screenshots would be ~1MiB). Forcing people (especially people who might be on dialup!) to download screenshots that they may not even care about is just plain rude. Not only is it rude, it's redundant, and pretty useless because the screenshots aren't allowed to have useful names (if you want them to show up on WordPress.org).
Now, let me turn the question around: what *is* the "logical reasoning for including screenshots in the release zip"? ;)
On 10/9/07, Travis Snoozy <ai2...@users.sourceforge.net> wrote:
> On Tue, 9 Oct 2007 11:58:04 -0700, "Lloyd Budd"
> Similarly, the screenshots don't need to be in the release zip > (especially since the images can't have reasonable names), but the > current packaging scheme *forces* the image files to be included if you > want the screenshots to show up on the site.
I was going to request that extend only pull in the screenshots from the trunk, that way we could tag releases without screenshots for the packager to create the downloads but the major problem would be the need for different screenshots for different tags. So the only solution I could think of would actually complicate things.
On Tue, 9 Oct 2007 16:07:36 -0700, "Daniel Cameron" <d...@scatter3d.com> wrote:
> On 10/9/07, Travis Snoozy <ai2...@users.sourceforge.net> wrote: > > On Tue, 9 Oct 2007 11:58:04 -0700, "Lloyd Budd"
> > Similarly, the screenshots don't need to be in the release zip > > (especially since the images can't have reasonable names), but the > > current packaging scheme *forces* the image files to be included if > > you want the screenshots to show up on the site.
> I was going to request that extend only pull in the screenshots from > the trunk, that way we could tag releases without screenshots for the > packager to create the downloads but the major problem would be the > need for different screenshots for different tags. So the only > solution I could think of would actually complicate things.
It makes sense to tag screenshots with the version, because they are in fact tied to that version. Everything resembling release X.Y.Z should be kept together -- that's the point of tagging. Michael had a good solution that I think hits pretty much everything:
On Tue, 9 Oct 2007 13:07:43 -0700, Michael D Adams <mi...@turbonet.com> wrote:
> What if the "Stable Tag" field in the readme could specify a > directory instead of just a tag name?
> Stable Tag: 2.1/sub-directory
This is an excellent idea. The screenshots would be able to stay with the tag, it's backwards-compatible with existing plugins, and it lets us control-freaks cleanly specify what we want zipped up and distributed. So long as the readme is pulled in from 2.1/, not 2.1/sub-directory, it should remain fully compatible with WordPress.org/extend.
> On 10/9/07, Travis Snoozy <ai2...@users.sourceforge.net> wrote: > > On Tue, 9 Oct 2007 11:58:04 -0700, "Lloyd Budd"
> > Similarly, the screenshots don't need to be in the release zip > > (especially since the images can't have reasonable names), but the > > current packaging scheme *forces* the image files to be included if you > > want the screenshots to show up on the site.
> I was going to request that extend only pull in the screenshots from > the trunk, that way we could tag releases without screenshots for the > packager to create the downloads but the major problem would be the > need for different screenshots for different tags. So the only > solution I could think of would actually complicate things.
Travis Snoozy wrote: > On Tue, 9 Oct 2007 16:07:36 -0700, "Daniel Cameron" <d...@scatter3d.com> > wrote:
>> On 10/9/07, Travis Snoozy <ai2...@users.sourceforge.net> wrote:
>>> On Tue, 9 Oct 2007 11:58:04 -0700, "Lloyd Budd"
>>> Similarly, the screenshots don't need to be in the release zip >>> (especially since the images can't have reasonable names), but the >>> current packaging scheme *forces* the image files to be included if >>> you want the screenshots to show up on the site.
>> I was going to request that extend only pull in the screenshots from >> the trunk, that way we could tag releases without screenshots for the >> packager to create the downloads but the major problem would be the >> need for different screenshots for different tags. So the only >> solution I could think of would actually complicate things.
> It makes sense to tag screenshots with the version, because they are in > fact tied to that version. Everything resembling release X.Y.Z should > be kept together -- that's the point of tagging. Michael had a good > solution that I think hits pretty much everything:
> On Tue, 9 Oct 2007 13:07:43 -0700, Michael D Adams <mi...@turbonet.com> > wrote:
>> What if the "Stable Tag" field in the readme could specify a >> directory instead of just a tag name?
>> Stable Tag: 2.1/sub-directory
> This is an excellent idea. The screenshots would be able to stay with > the tag, it's backwards-compatible with existing plugins, and it lets > us control-freaks cleanly specify what we want zipped up and > distributed. So long as the readme is pulled in from 2.1/, not > 2.1/sub-directory, it should remain fully compatible with > WordPress.org/extend.
Michael D Adams wrote: > On Oct 9, 2007, at 12:42 PM, Travis Snoozy wrote: >> It's a great big PITA if you have files you don't want to distribute, >> though.
> What if the "Stable Tag" field in the readme could specify a directory > instead of just a tag name?
> Stable Tag: 2.1/sub-directory
> would result in tags/2.1/sub-directory/ being packaged as the download > zip. For the "Other Versions" section of the plugin directory, we'd > probably still package the whole "root" directory (tags/2.1/) because > we can't know if all tags have the same directory structure.
On 10/16/07, Callum Macdonald <lists.automattic....@callum-macdonald.com> wrote:
> Did anything ever come of this suggestion? I don't remember seeing any > opposition to it and I saw several people supporting it.
> Is there a process which needs to be followed to get this done or do we > just need to pester Matt?
I think the general consensus might be that it works fine as is.
If that's not the case, then I'd say (as you suggest) that the first step is determining if this part of code is open for discussion, and if so, what that process should be.
If we are considering possible changes, I'd throw in the suggestion for allowing (or actually requiring) the readme screenshot images to be named references to files, rather than files named according to the current convention.
Then you could allow these file references to have an attribute indicating whether the packager should include it in the zip of not. _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
On Sun, 21 Oct 2007 21:21:01 -0700, "Jared Bangs" <ja...@pacific22.com> wrote:
> On 10/16/07, Callum Macdonald > <lists.automattic....@callum-macdonald.com> wrote:
> > Did anything ever come of this suggestion? I don't remember seeing > > any opposition to it and I saw several people supporting it.
> > Is there a process which needs to be followed to get this done or > > do we just need to pester Matt?
> I think the general consensus might be that it works fine as is.
Based on...? I've seen only one person settle on "leave it be." It's not exactly easy to tell the difference between "vocal minority" and "silent consensus." ;)
> If that's not the case, then I'd say (as you suggest) that the first > step is determining if this part of code is open for discussion, and > if so, what that process should be.
Indeed. Who's the maintainer? It's not exactly listed anywhere; I assume from skimming some trac tickets that we have to go through Matt or Mike.
> If we are considering possible changes, I'd throw in the suggestion > for allowing (or actually requiring) the readme screenshot images to > be named references to files, rather than files named according to > the current convention.
> Then you could allow these file references to have an attribute > indicating whether the packager should include it in the zip of not.
Yeah, but my coder's intuition tells me that's getting into a bigger, more complex change in code, and it also solves a narrower issue. Indicating a subdirectory provides a lot more leverage over package contents for the effort. I totally agree that screenshots should be allowed to have real names (the way it is now is totally lame), but the inclusion issue can be solved independently, so we don't need to tie the two solutions together.
I think most people are probably just fine with how it is, but not opposed to the previously suggested suggestion (but not really in favor of it either). Or at least that's how I feel.
On 10/22/07, Travis Snoozy <ai2...@users.sourceforge.net> wrote:
> On Sun, 21 Oct 2007 21:21:01 -0700, "Jared Bangs" <ja...@pacific22.com> > wrote:
> > On 10/16/07, Callum Macdonald > > <lists.automattic....@callum-macdonald.com> wrote:
> > > Did anything ever come of this suggestion? I don't remember seeing > > > any opposition to it and I saw several people supporting it.
> > > Is there a process which needs to be followed to get this done or > > > do we just need to pester Matt?
> > I think the general consensus might be that it works fine as is.
> Based on...? I've seen only one person settle on "leave it be." It's > not exactly easy to tell the difference between "vocal minority" and > "silent consensus." ;)
> > If that's not the case, then I'd say (as you suggest) that the first > > step is determining if this part of code is open for discussion, and > > if so, what that process should be.
> Indeed. Who's the maintainer? It's not exactly listed anywhere; I > assume from skimming some trac tickets that we have to go through Matt > or Mike.
> > If we are considering possible changes, I'd throw in the suggestion > > for allowing (or actually requiring) the readme screenshot images to > > be named references to files, rather than files named according to > > the current convention.
> > Then you could allow these file references to have an attribute > > indicating whether the packager should include it in the zip of not.
> Yeah, but my coder's intuition tells me that's getting into a bigger, > more complex change in code, and it also solves a narrower issue. > Indicating a subdirectory provides a lot more leverage over package > contents for the effort. I totally agree that screenshots should be > allowed to have real names (the way it is now is totally lame), but the > inclusion issue can be solved independently, so we don't need to tie > the two solutions together.
> On Oct 9, 2007, at 12:42 PM, Travis Snoozy wrote: >> It's a great big PITA if you have files you don't want to distribute, >> though.
> What if the "Stable Tag" field in the readme could specify a directory > instead of just a tag name?
> Stable Tag: 2.1/sub-directory
> would result in tags/2.1/sub-directory/ being packaged as the download > zip. For the "Other Versions" section of the plugin directory, we'd > probably still package the whole "root" directory (tags/2.1/) because > we can't know if all tags have the same directory structure.
Matt Mullenweg wrote: > Callum Macdonald wrote: >> I emailed Matt Mullenweg directly about it, no response as yet. > 1. I don't have an email from you. > 2. From reading earlier messages in this thread it seems like it's > working fine for everyone else.
1) Not sure what happened, it was sent 24/10/07 10:35 to m ~at- mullenweg~com from the address I use to post to the list.
2) 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.
> 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:
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).
|
