The library has started as WebBits at Brown University, and many people have contributed to it since. See language-ecmascript.cabal for the list of contributors and copyright information.
Since version 0.17.0.1 the library follows Haskell Package Versioning Policy (https://wiki.haskell.org/Package_versioning_policy) for its version numbers. The version is a triple of numbers MAJOR1.MAJOR2.MINOR(.PATCH), where the last number is optional and:
- MAJOR1 and MAJOR2 are incremented only on backwards-incompatible and reverse-dependency-breaking changes,
- MINOR is incremented on any additional backwards-compatible features,
- PATCH is incremented on any other changes, mostly bug/build-fixes.
If your publicly-released package depends on this library you are strongly encouraged to restrict allowed versions to at least the MAJOR version you are using.
Starting the next major version release, the library is going to follow the following versioning scheme (compatible with PVP): ESS.MAJOR.MINOR.PATCH, where
- MAJOR, MINOR and PATCH are as above, and
- ESS corresponds to the version of the ECMAScript standard the library supports.
Contributions are welcome, provided they are in agreement with the terms of the BSD3 license. Generally, any non-trivial (beyond formatting, spelling or simple bug/build fixes) contribution is to be reflected in the list of contributors. The preferred method of contribution is via pull requests. If you intend to contribute a lot, after your first pull request is accepted, you can get direct commit rights to the repository. As a contributor you are expected to follow the general formatting style and document your efforts in the source code comments and in the issue discussion.
If you would like to contribute, here's how you can get started:
- Read the Roadmap wiki page (https://github.com/jswebtools/language-ecmascript/wiki/Roadmap) to get an idea of where the project is heading and where the current efforts are focused.
- Head to the issues list (https://github.com/jswebtools/language-ecmascript/issues), read through the issues and pick an issue to work on. If someone is already working on it, contact them first to make sure you are not stepping on each other's toes.
- (Optional) Send an e-mail to the maintainer, Andrey Chudnov email@example.com, to let him know what you are planning to work on and ask any questions you have about the problem or the code base.