A process for core library fixes and improvements

Request Feedback
43

I’ve been a consumer of both Lua and SQLite. They both appear to follow these principles:

  1. The core is under strict control of the author or author(s). Maybe they’ll look at pull requests, but it is largely the work of a single individual or a small set of individuals.

  2. The core is “small”. For Lua, it’s just the language and the core libraries defined as part of the language standard. For SQLite, it’s the SQL implementation.

  3. Bugs in releases are fixed very quickly in double-dot-releases. They generally stabilize out these bugs quickly but there have been occasional patches to older releases. Versions before a certain point are not patched, but anything expected to be potentially in use does get patched.

It seems like Elm matches up on 1. It is over expansive in the efforts about control on 2 though there is a pretty clear boundary that could be drawn about what is inside the scope of control/responsibility and what is not. On 3, this is clearly not the behavior since many bug fixes if they ever come also tend to come with significant language revisions. I feel that 1 is a healthy choice because it provides a clarity that committee driven processes often lack. It is, however, enabled for the community by 3 which is further enabled by 2.

4 Likes