Web Application Submission Guidelines

From DreamHost
Revision as of 16:20, 14 January 2011 by WesleyS (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Header OCI.png

Want to submit your shiny application to our crazy catalog!? No way! Awesome!

So before you click that crazy little "Submit" button, there's just a few things you should know...

Don't worry, it's not much, but we want to ensure that things are easy peezy!

Where can I submit my application?

You can easily review your submissions and submit your new/updated application here!

But I don't have a DreamHost account

No worries at all! You can sign up for a FREE Application Developer login here!

I'm not the developer, but I want to share it with the world!

Sorry, but at this time, we're only accepting submissions from the application developers themselves.

Guidelines

Your Submission

Okays! Here's the general bit you need to know, summed up!

  • Your download link should point to a specific version of the application, and not something that's always changing. For example, "latest.zip" is not acceptable.
    • If you change that download at that address or remove it, we will retroactively reject your application for our customer's safety and security!
    • Why!?!?!? Well, simply put, to prevent a malicious developer from going and submitting an application, getting it approved, and then putting something nasty in the download package. Our installer checks the checksums of the download, and if it doesn't match, your application will not be installed, and will end up being rejected.
  • Keep your Short Description short. Think of it like a tag line or catch phrase, to get someone's attention, without being deceitful.
  • For the icon and screen shot, you may want to provide a URL to an image that is already the right size. If the URL you provide is not, then we're going to resize it automatically, and it may not look as pretty afterwards!
  • The download link must point to a compressed archive. If it's pointed to some silly "where to download" type page, it's going to be rejected.
    • The only exception to this is things like SourceForge.net's direct file download system -- when viewed in a browser, they show a HTML page and redirect you. However, when you download them via wget, it takes you straight to the download with no fuss. :)
  • We do not support downloading from SCMs (cvs, svn, git, etc).
  • Also keep in mind the tag and package guidelines below!

Tags

Okay, I know this may seem silly, but it does matter. A lot. Like how water matters to fish!

Generally speaking, a tag should be just common terms, that identify what purpose your application serves, and what it'd provide to customers.

Now there are a few things that simply shouldn't be used.

  • If a similar tag already exists on the installer, use it. For example, don't use "forums" or "ecommerce". Instead use "Forum" or "E-Commerce", respectively. (We don't want the installer getting all ugly-like.)
  • This also goes for pre-existing short versions of a tag. Don't "Content Management System". Use the existing version, "CMS". It's the same thing, and a lot more pretty!
  • Don't use silly terms -- they don't tell the users anything about your application. For example, using the term "social" doesn't tell me what it does.
  • Do not use terms indicating what technologies your application utilizes. For example, don't use: "www", "http", "php", "mysql" -- Seriously! Most end users do not care that your site uses PHP with a MySQL backend.
  • Some tag names are reserved, and can't be used at all. If you attempt to use one of them, you'll get an error telling you to remove it.

Packaging

Now, we're not saying you have to have some big box with a fancy logo and a lot of text. We're not THAT crazy! (Okay, maybe we are, but we wouldn't do that to you!)

Pretty much we have a simple, no-nonsense philosophy on how things should be packaged.

  • All of the files for the site must reside in the zip file directly -- not in a folder.
  • If they are in a folder, and there is only one file/folder in the root of the archive, not a worry -- the installer can handle that!
  • If there is more than one file/folder in the root of the archive, then it will be rejected, since that doesn't make the installer too happy.

Updates

So this is something you'll definitely want to keep an eye out for! Say your configuration information exists in a file called 'config.php'. In which case, the package you distribute should not have a 'config.php' file there -- instead, maybe name it 'config.sample.php'.

Why? Simple! When the installer processes an update, it's going to overlay your new archive directly on top of the old install, and if you include a 'config.php' file, it's going to end up overwriting the original one!

Known Problematic Archive Programs

The following programs have been reported to create archives that Debian's unzip does not like.

  1. jZip -- the Debian Linux 'unzip' utility doesn't like archives made by this program, since jZip doesn't set all fields correctly.
  1. Mac OS X built-in Compression -- Creates extra meta-data folders specific to OS X, that violates the package guidelines.

Alternatives?

For Windows, try 7-Zip (free) or WinZIP (paid).

For OS X, try YemuZip (free for personal use) or Compress ("completely free")


Told you it was easy!

Questions?

If you have any questions about this or submitting your application, feel free to send a message to support. I promise we don't bite. :)