Guidelines for Hackage Packages:
In addition to the main package list page, there are a few other package indices:
Uploading a package puts it in the main package index +
Uploading a package puts it in the package index so that anyone can download it and view information about it. You can only upload a package version once and this cannot be undone, so try to get it right the first time! To reduce the risk of mistakes it's recommended to use the package candidates feature described below. @@ -28,13 +28,6 @@ synopsis/description as well as ensuring your package is installable by helping with providing accurate meta-data.
-In the course of the curation process, the -Hackage Trustees need to be -able to contact you, to inform you about and help you resolve issues with -your package (including its meta-data) which affect the Hackage -ecosystem. -
-Packages must be in the form produced by Cabal's sdist command: a gzipped tar file package-version.tar.gz @@ -43,12 +36,28 @@ of that name and version, including package.cabal. See the notes at the bottom of the page.
-In order to ensure the integrity and well-functioning of the Hackage/Cabal ecosystem, all packages should follow Haskell's Package Versioning Policy (PVP).
+By default, uploaded packages are curated which means that both maintainers and hackage trustees may revise their metadata (particularly involving version bounds) to guide build tools in producing install-plans. (For more information on revisions, see the FAQ). + +
In order to ensure the integrity and well-functioning of the Hackage/Cabal ecosystem, all curated packages should follow Haskell's Package Versioning Policy (PVP).
In particular, be aware that although the PVP and SemVer are based on the same concepts they differ significantly in structure and consequently are not compatible with each other. Please consult the PVP/SemVer FAQ section for more details about the differences and related issues.
+ +Further, an important property of the PVP contract is that it can only be effective and provide strong enough guarantees if it is followed not only by an individual package, but also by that package's transitive dependencies. Consequently, packages which are curated should aim to depend only on other curated packages.
+In the course of the curation process, the +Hackage Trustees need to be +able to contact package maintainers, to inform them about and help to resolve issues with +their packages (including its meta-data) which affect the Hackage +ecosystem.
+ +Package uploaders may choose to exclude individual package uploads from curation, by setting the x-curation: field of the package's cabal file to uncurated. Packages which are uncurated have no expectations on them regarding versioning policy. Trustees or maintainers may adopt uncurated packages into the curated layer through metadata revisions. Metadata revisions must not set the value of the x-curation field to any variant of uncurated.
+ +Two variants of the uncurated property are supported. First, uncurated-no-trustee-contact, which indicates that maintainers do not wish to be contacted by trustees regarding any metadata issues with the package. (Contact may still occur over issues that are not related to curation, such as licensing, etc.). Second, uncurated-seeking-adoption, which indicates that maintainers would like their package to be adopted in the curated layer, but currently some issue prevents this, which they would like assistance with.
+ +In the future, metadata regarding curation will be made available in the UI of Hackage, and different derived indexes will be provided for the uncurated and curated layers of packages.
+The code and other material you upload and distribute via this site must be