hackage-server-0.4: datafiles/templates/upload.html.st
<!DOCTYPE html>
<html>
<head>
$hackageCssTheme()$
<title>Hackage: Uploading packages and package candidates</title>
</head>
<body>
$hackagePageHeader()$
<div id="content">
<h2>Uploading packages and package candidates</h2>
<p>Uploading a package puts it in the <a href="/packages/">main package index</a>
so that anyone can download it and view information about it. You can only
upload a package version once, so try to get it right the first time!
</p>
<p>You can also upload a <a href="/packages/candidates">package <em>candidate</em></a>
to preview the package page, view any warnings or possible errors you might
encounter, and let others install it before publishing it to the main index.
(Note: you can view these warnings with 'cabal check'.) You can have multiple
candidates for each package at the same time so long as they each have different
versions. Finally, you can publish a candidate to the main index if it's not
there already.
</p>
<p>If you upload a package or package candidate and no other versions exist
in the package database, you become part of the maintainer group for that
package, and you can add other maintainers if you wish. If a maintainer group
exists for a package, only its members can upload new versions of that package.
</p>
<p>If there is no maintainer, the uploader can remove themselves from the group,
and a <a href="/packages/trustees">package trustee</a> can add anyone who wishes
to assume the responsibility. The <tt>Maintainer</tt> field of the Cabal file should be
<tt>None</tt> in this case. If a package is being maintained, any release not approved
and supported by the maintainer should use a different package name. Then use
the <tt>Maintainer</tt> field as above either to commit to supporting the fork
yourself or to mark it as unsupported.
</p>
<p>Note that all of the above is a makeshift upload policy based on the features
available in the newer hackage-server. The <tt>Maintainer</tt> field has its uses,
as does maintainer user groups. The libraries mailing list should probably
determine the best approach for this.
</p>
<h3>Upload forms</h3>
<p>Some last formalities: to upload a package, you'll need a Hackage
<a href="accounts.html">username</a> and password. (Alternatively, there's a
command-line interface via cabal-install, which also needs the same username
and password.)
</p>
<p>Packages must be in the form produced by Cabal's
<a href="http://www.haskell.org/ghc/docs/latest/html/Cabal/builders.html#setup-sdist">sdist</a> command:
a gzipped tar file <em>package</em>-<em>version</em><tt>.tar.gz</tt>
comprising a directory <em>package</em>-<em>version</em> containing a package
of that name and version, including <em>package</em><tt>.cabal</tt>.
See the notes at the bottom of the page.
</p>
<div style="font-size: large; text-align: center;"><a href="/packages/upload">Upload a package</a></div>
<div style="font-size: large; text-align: center;"><a href="/packages/candidates/upload">Upload a package candidate</a></div>
<h3>Notes</h3>
<ul>
<li>You should check that your source bundle builds,
including the haddock documentation if it's a library.</li>
<li>Categories are determined by whatever you put in the <tt>Category</tt> field
(there's no agreed list of category names yet).
You can have more than one category, separated by commas. If no other versions of
the package exist, the categories automatically become the package's tags.</li>
<li>Documentation for library packages should be generated by a maintainer.
The means of doing this is still up in the air.</li>
<li>We have moved to Haddock 2, and expect some glitches.
If you notice anything broken, please report it on the
<a href="http://trac.haskell.org/haddock">Haddock bug tracker</a>.</li>
<li>In GHC 6.8, several modules were split from the <tt>base</tt> package
into other packages.
See <a href="http://www.haskell.org/haskellwiki/Upgrading_packages">these notes</a> on making packages work with a range of versions of GHC.</li>
<li>While <a href="http://www.haskell.org/haddock/">Haddock 2</a>
accepts GHC features, it is also more picky about comment syntax than
the old version.</li>
</ul>
</div>
</body>
</html>