Meta tags:

Headings (most frequently used words):

and, package, uploading, packages, version, history, change, logs, versioning, curation, open, source, licenses, public, repositories, privileges, group, accounts, candidates, notes,

Text of the page (most frequently used words):
the (89), package (61), and (38), that (28), you (21), are (20), for (20), #packages (16), can (16), not (15), hackage (14), upload (12), cabal (11), with (10), this (9), have (9), other (9), maintainer (9), any (8), source (8), uncurated (8), which (8), version (7), maintainers (7), should (7), candidates (7), group (7), only (7), use (7), metadata (7), curation (7), curated (7), from (6), versions (6), license (6), code (6), open (6), issues (5), but (5), see (5), field (5), your (5), name (5), these (4), existing (4), check (4), being (4), documentation (4), their (4), dir (4), some (4), notes (4), including (4), what (4), index (4), each (4), file (4), new (4), all (4), right (4), service (4), will (4), trustees (4), may (4), pvp (4), changelog (4), uploading (4), particular (3), also (3), maintained (3), repositories (3), haddock (3), publish (3), tar (3), changes (3), there (3), well (3), categories (3), more (3), candidate (3), still (3), page (3), view (3), main (3), same (3), they (3), different (3), want (3), individual (3), accounts (3), case (3), need (3), distribute (3), licenses (3), operate (3), must (3), policy (3), regarding (3), contact (3), versioning (3), revisions (3), about (3), preferable (2), following (2), fields (2), repository (2), public (2), users (2), before (2), bug (2), history (2), useful (2), build (2), library (2), below (2), note (2), two (2), ones (2), set (2), docs (2), work (2), needs (2), done (2), make (2), compatible (2), try (2), possible (2), than (2), one (2), category (2), exist (2), become (2), warnings (2), others (2), install (2), time (2), account (2), people (2), recommended (2), uploads (2), remove (2), add (2), anyone (2), supported (2), either (2), none (2), trustee (2), wish (2), its (2), url (2), please (2), material (2), includes (2), format (2), derived (2), uploaded (2), operators (2), rights (2), those (2), choose (2), enough (2), able (2), under (2), our (2), community (2), property (2), first (2), indicates (2), related (2), would (2), like (2), layer (2), them (2), value (2), meta (2), data (2), ecosystem (2), provide (2), consequently (2), based (2), semver (2), faq (2), information (2), names (2), txt (2), news (2), markdown (2), alphabetic (2), exception (2), cannot (2), web, pages, linked, publicly, accessible, where, refer, gives, access, duplicates, raising, enables, gauge, whether, actively, developed, said, links, private, acceptable, just, server, attempts, fail, generate, own, using, something, along, lines, shell, script, last, commands, key, bin, mktemp, dist, xxxxxx, trap, exit, assumes, later, builddir, enable, doc, occasional, ghc, base, mean, across, range, tips, how, upgrading, much, older, determined, whatever, put, pick, when, separated, commas, automatically, tags, bundle, builds, yet, been, fully, implemented, improved, overview, project, dashboard, way, preview, errors, might, encounter, let, publishing, multiple, long, finally, already, occasionally, organizations, organizational, approach, cases, managing, list, uploader, themselves, who, wishes, assume, responsibility, release, approved, then, above, commit, supporting, fork, yourself, mark, unsupported, database, part, exists, members, password, username, privileges, homepage, report, sure, comply, example, tarball, files, 3rd, party, include, certain, derivatives, conversions, limited, modified, excerpts, presentation, alternative, presentations, formats, html, markup, expect, consequence, asking, beyond, granted, normal, grant, business, making, judgements, valid, retain, spirit, conflict, ability, advice, recommends, via, site, operated, benefit, compliance, copyright, laws, future, made, available, indexes, provided, layers, variants, contacted, occur, over, such, licensing, etc, second, adopted, currently, issue, prevents, assistance, seeking, adoption, uploaders, exclude, setting, expectations, into, through, variant, adopt, course, process, inform, help, resolve, affect, further, important, contract, effective, strong, guarantees, followed, transitive, dependencies, aim, depend, aware, although, concepts, differ, significantly, structure, consult, details, differences, section, order, ensure, integrity, functioning, follow, haskell, default, means, both, revise, particularly, involving, bounds, guide, tools, producing, plans, matched, insensitively, extension, change_log, basename, plain, text, link, corresponding, filenames, recognized, change, logs, unicode, point, however, rejects, points, latin, alphabet, insensitive, comparison, form, produced, command, gzipped, comprising, directory, containing, bottom, sdist, because, added, has, cost, operation, maintenance, associated, entails, giving, meaningful, synopsis, description, ensuring, installable, helping, providing, accurate, strive, intended, puts, download, get, reduce, risk, mistakes, described, feature, once, undone, permanently, user, browse, search,

Text of the page (random words):
uploading packages and package candidates hackage hackage package search browse what s new upload user accounts uploading packages upload and publish a package permanently upload 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 because each package added to the main package index has a cost of operation and maintenance associated to it your package should strive to provide value for the community by being intended to be useful to others which entails giving your package a meaningful synopsis description as well as ensuring your package is installable by helping with providing accurate meta data 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 a cabal package name can use any alphabetic unicode code point however hackage rejects package names that use alphabetic code points other than those from the latin alphabet that is a to z and a to z with one exception the name of a new package cannot be the same as the name of an existing package based on a case insensitive comparison the exception is if the maintainer uploading the new package is a maintainer of the existing package version history and change logs if a package includes a changelog file in either plain text or markdown format hackage will link to it on the corresponding package page the following filenames are recognized basename change_log changelog changes news extension none txt md markdown changelog names are matched case insensitively news changes txt and changelog md will all work package versioning and curation 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 open source licenses the code and other material you upload and distribute via this site must be under an open source license this is a service operated for the benefit of the community and that is our policy it is also so that we can operate the service in compliance with copyright laws the hackage operators do not want to be in the business of making judgements on what is and is not a valid open source license but we retain the right to remove packages that are not under licenses that are open source in spirit or that conflict with our ability to operate this service if you want advice see the ones cabal recommends the hackage operators do not need and are not asking for any rights beyond those granted by the open source license you choose to use all normal open source licenses grant enough rights to be able to operate this service in particular we expect as a consequence of the license that we have the right to distribute what you have uploaded to other people we have the right to distribute certain derivatives and format conversions including but not limited to documentation derived from the package alternative presentations and formats of code e g html markup excerpts and presentation of package metadata modified versions of package metadata please make sure that you comply with the license of all code and other material that you upload for example check that your tarball includes the license files of any 3rd party code that you include public repositories it is preferable if any web pages linked from the following fields are publicly accessible bug report url homepage url source repositories in particular where these fields refer to a repository a public repository is preferable this gives users access to existing issues e g to check for duplicates before raising a bug and package version history it also enables users to gauge whether packages are being actively maintained or developed that said links to private repositories are acceptable just not as useful privileges 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 the maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported group accounts occasionally organizations want to have a group organizational account for a package that is maintained by a group of people the recommended approach for these cases is to only do package uploads from individual accounts and use the group account only for managing the maintainer list for the package package candidates 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 and are still being improved see package candidates project dashboard for an overview of what still needs to be done upload a package candidate notes 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 category field you should try to pick existing categories when possible 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 occasional changes to the ghc base package can mean that some work needs to be done to make packages compatible across a range of versions see these notes for some tips in how to do so there are some notes for upgrading much older packages as well the hackage server attempts to build documentation for library packages but this can fail maintainers can generate their own documentation and upload it by using something along the lines of the shell script below note that the last two commands are the key ones bin sh set e dir mktemp d dist docs xxxxxx trap rm r dir exit assumes cabal 2 4 or later cabal v2 haddock builddir dir haddock for hackage enable doc cabal upload d publish dir docs tar gz