Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

To take an existing project and turn it into a clojure-contrib project:

All past contributors on the project must:

The email should say:

"I, (YOUR NAME), give my permission to release my contributions to (PROJECT) under the Clojure Contributor Agreement."

Once a project is in contrib:

  • Patches may only be accepted from signers of the CA
  • All contributions are automatically governed by the terms of the CA

Achieving a 1.0.0 release

In order to be approved for a 1.0.0 release (by Clojure/core), a contrib library must satisfy the following criteria (work in progress, original list by Stuart Halloway):

  • Stability and production use.
  • Some amount of time in #1 to get community feedback. (How long?)
    • Time and number of installations both factor in here - wide usage seems important to me (Sean).
  • Conformance with Clojure idioms.
    • In particular: Library Coding Standards.
    • Current discussion on ML about 'foo' function / macro delegating to 'foo*' implementation and whether that is idiomatic.
  • Careful review to avoid unnecessary dependencies.
    • Consensus from previous discussions seems to be:
      • Dependence on core is fine.
      • Dependence on new contrib is OK if really necessary.
      • Dependence on anything else is subject to intense review and challenge.
  • Simplicity / Power / Focus.
    • This is a bit wooly and will need refinement to help contrib library developers.
    • Composability seems a common theme in discussions:
      • Prefer functions over macros.
      • Prefer explicit arguments over bindings.
    • On macros, the Library Coding Standards says to expose a function first and add a macro only where it provides ease-of-use.
  • Avoid AOT requirement if at all possible.
  • Motivated maintainer.