[wp-hackers] Plugin zip problem on wordpress.org
Travis Snoozy
ai2097 at users.sourceforge.net
Tue Oct 9 22:45:11 GMT 2007
On Tue, 09 Oct 2007 17:45:40 -0400, Keith Constable
<kccricket at 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"? ;)
--
Travis
In Series maintainer
Random coder & quality guy
<http://remstate.com/>
More information about the wp-hackers
mailing list