A process for core library fixes and improvements

Besides tooling, another reason not to fork more aggresively is the compiler and language itself. There is still work going on there by Evan, and the further away a fork gets from the original, the harder it becomes to pick up what he builds in the next version of Elm. That is why I advocate a Release Branch approach, at least until such time as everything that can be fixed in a release branch has been fixed. It would give us the opportunity to at least fix some stuff and get things moving. Its not possible to say exactly how much of that stuff might be able to carry forward into a newer version of Elm, but it seems likely at least some patches would carry over cleanly.

I don’t see a hurry to fork, there is plenty time. I did Java for 20 years, and now its becoming possible to make a living doing Elm, maybe I’ll be here for 20 years too. So I am enjoying this thread and listening to peoples points of view and spending some time thinking about possible directions and what is best for all.

1 Like