Upload a package
Uploading a package puts it in the main package index 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!
Packages must be in the form produced by Cabal's sdist command: a gzipped tar file package-version.tar.gz comprising a directory package-version containing a package of that name and version, including package.cabal. See the notes at the bottom of the page.
To upload a package, you'll need a Hackage username and password.
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.
If there is no maintainer, the uploader can remove themselves from the group,
and a package trustee can add anyone who wishes
to assume the responsibility. The
Maintainer field of the Cabal file should be
None 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
Maintainer field as above either to commit to supporting the fork
yourself or to mark it as unsupported.
Note that all of the above is a makeshift upload policy based on the features
available in the newer hackage-server. The
Maintainer field has its uses,
as does maintainer user groups. The libraries mailing list should probably
determine the best approach for this.
Package Candidates (Tech Preview)
Package candidates are a way 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.
Package candidates have not yet been fully implemented; see Issue 41 for an overview of what still needs to be done.
- You should check that your source bundle builds, including the haddock documentation if it's a library.
Categories are determined by whatever you put in the
Categoryfield (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.
- Documentation for library packages should be generated by a maintainer. The means of doing this is still up in the air.
- We have moved to Haddock 2, and expect some glitches. If you notice anything broken, please report it on the Haddock bug tracker.
In GHC 6.8, several modules were split from the
basepackage into other packages. See these notes on making packages work with a range of versions of GHC.
- While Haddock 2 accepts GHC features, it is also more picky about comment syntax than the old version.