[Haskell-cafe] Policy for taking over a package on Hackage

[KQ]

On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley <stephen.tetley at gmail.com> wrote:

> Hi Ivan
>
> Forks are good, no?
>
> The Parsec experience has suggested to me at least, that new author's
> "capping" another author's work by bumping up to a major version,
> causes a significant difficulties even when the original author has
> gone.
>
> As for wl-pprint, it was a very tidy library in its original
> implementation - it's a pity it now has name clashes with Applicative.
> My feeling is that a new library in a new namespace with some
> attention to new combinator names would be better.

At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal:

Add to the .cabal file the following optional field:

        Related-package: ACTION NAME VERSION Information

  - The first word is the ACTION and is one of: "Replaces", "Redesigns", "Extends", or "Alternative".

  - The second word is the NAME of the related package.

  - The third word is the VERSION of the related package.

  - Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field.

There may be multiple "Related-package" entries specifying different packages and actions.

Conceptually, the ACTION indicates:

    - Replaces: This package is intended as a newer replacement to use instead of the older package.  It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well   (this is probably what Ivan's new package would specify).

    - Redesigns: This package is intended as a replacement for the older package.  It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes.  An example of this would be Parsec2 and Parsec3.

    - Alternative: This package is a horizontal replacement for the other package providing the same type of functionality.  The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same.  The Information should describe the difference between the two.

    - Extends: This package uses the previous package and extends it with complementary functionality.  For example, attoparsec-binary extends attoparsec.


I would suggest the ACTION be limited to known terms such as the above, whereas the Information is free-form for more clarification.  The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well.

The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section "This package has a Redesign:  parsec3.  The redesign states:  ...[Information]......".   This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations).

Thoughts?

-- 
-KQ