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

[Antoine Latter]

On May 25, 2011 11:08 AM, "KQ" <quick at sparq.org> wrote:
>
> 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?
>

The only thing I'd add would be the additional actions "ReplacedBy",
"ExtendedBy" and "RedesignedBy".

Antoine

> --
> -KQ
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110525/eaa88b8f/attachment-0001.htm>