2017 is the first time we don’t get new release of Elm. Could it be possible that we don’t get new release for 2 years or more?
Something is true for every release: it will be done when it’s done.
7 Likes
Hey!
So there’s actually a few great resources covering how Elm is developed here:
The general gist is that work on Elm is happening all the time, but Evan is putting things together in a way that makes the next release of Elm make sense. Since there may be a bunch of implementation changes that need to happen, big batches of work get grouped together, so releases don’t happen so frequently.
Likewise, Elm 0.18 as it is a great language and works right now – aside from a few bugs, releasing a new feature for the sake of change does not make sense: instead releasing when everything fits together in a way that makes sense for Elm in super beneficial to us, the users. It gives us stability.
9 Likes
The frustrating thing is that bug fixes seem tied to feature additions, so if the features take a long time, the bug fixes don’t become available. Where is Elm 0.18.1?
Mark
9 Likes
I don’t want to comment on Evan’s behalf, but:
- A lot of the work for 0.19 involved re-writing large parts of the underyling system, which made bugfix releases require “all” the changes to be published, not just parts
- I’ve discussed this with him previously, and from what I recall, bugfix releases is something that will happen more frequently going forward. I might be recalling incorrectly, however.
- Some of the investigative work that you may follow on Github has been to split things up in a way that makes bugfix releases easier to release
14 Likes
maybe a stable-release-maintainer is what’s called for…
3 Likes
Given 0.19 and not 1.19, I wouldn’t count on it.
I can readily see how this might apply to some of the compiler issues with recursive types, but what about the thing new Elm developers raise with me: the inability to read messages in full in the debugger. That’s not much more than CSS i think?
6 Likes
The specific work to make those messages visible is a straightforward visual change, yes. But the links that Noah shared explain that releases are done in batches in order to create cohesive changes that can be communicated well. So in addition to the visual update, the debugger needs to be moved to a new package to account for how program startup will work in 0.19. Then its native code needs to be updated to the 0.19 format. Then optimizations that 0.19 enables need to be introduced into the debugger code. And we have to make sure all of that is done in a way that doesn’t make long-term plans more difficult to achieve. There’s more to delivering open source software at this scale than ticking off github issues, and thinking about it that way results in disproportionate and distracting pressure from the community on developers to Just Fix The Bugs And Release, How Hard Can It Be?
6 Likes
Certainly introducing features as part of cohesive releases is valuable, but I think it’s worth asking whether coupling fixes for outstanding issues to those releases (especially when the fixes could be self-contained) helps or hinders the community and ecosystem.
The current organizational structure of the Elm project makes these sort of bugfix releases expensive, but I have participated in other open source communities where the (often thankless) work of triaging issues and wrangling fixes was delegated to community members who had the time and will to contribute. The Ember project comes to mind specifically. I’m sure some people from that project would be willing to discuss their approach and its relative advantages/disadvantages.
IMO it ultimately comes down to sharing the burden of maintenance so that we can all reap the benefits of a more solid foundation. I think this is possible to do without compromising on a coherent vision.
6 Likes
Even without shared maintenance, some of the most successful open source projects — e.g., SQLite which for a long time was essentially just the work of Richard Hipp — have managed to maintain a practice of rapidly releasing bug fixes for the existing official release while still developing the next release. I’m sure some times this requires making the fix twice but it also means that the community to whom the software is being released isn’t stuck trying to figure out how to work around a buggy release.
Elm’s version history also potentially exacerbates the problems associated with tying bug fixes to feature releases in that some times those releases cause enough disruption that they are difficult to adopt. 0.17 to 0.18 was pretty simple but there is at least one project that noisily abandoned Elm because of the elimination of FRP in 0.17. Dropping FRP may have been the right choice for Elm as a language but the precedent that has been established is that one needs to not expect interim bug fixes to Elm AND when bug fixes do arrive they may arrive in a form that is difficult to adopt.
My general point is that, as a developer, I’m sympathetic to it being difficult to deliver bug fixes while independently delivering features. It would be nice to know that there was sympathy for the difficulties that the choice not to do so causes.
Mark
7 Likes
No, it does not need to be moved to a new package. Some bugfixes can be easily retrofitted to previous releases. I think the CSS changes for the debugger fit easily into this category.
The changes can be communicated well with major and minor releases. With a minor release it can be just a change log of bug fixes. With a major release it can be something more complex, maybe an extensive blog post some marketing efforts, posting stuff on various news outlets, etc.
Nobody denies that there is more to delivering OSS than just ticking off github issues but let’s not pretend like there is nothing wrong here. There are no “developers” of Elm. There is only Evan. If there would have been 2, Evan would have been free to develop 0.19 while the second developer could have maintained 0.18. Since there is only one developer, 0.18 remained unmaintained. There were no bugfixes to it. Not even the lowest hanging fruits. With this approach in place, even highly impactful changes like the compilation flags discovered by the people exploring the compilation time issues could not be released for the public. That change does not even require a single line of code to be changed in the compiler and it has cut my compilation time in half in certain painful places.
11 Likes
link please … 
Not disputing anything you said which is all valid, but isn’t that the point of setting the version number to 0.18? I’d consider that version number to be an alpha release, beta as it gets closer to 1.0, and only from 1.0 onward to be a supported and maintained release. Is Elm in fact an alpha that became too successful?
I’d like to know what the plan is to get from 0.19 to 1.0.
3 Likes
I lost the link. It was in #compile-time but it is lost due to message limit. The slackarchive does not have anything archived for that channel past January 15.
This pull request has more information.
1 Like
There was a compile time thread here recently.
On mobile now, but you have to recompile elm-make with different flags, I posted some binaries over here https://github.com/hpate-omicron/elm-make/releases for Linux and Mac.
You can run your current build with elm-make +RTS -s -RTS, if a ton of time is spent in the garbage collector then the recompilied binaries will help a lot, the flags that have worked best for me are -A128M -H128M -n8m
1 Like
As for the “Is Elm in fact alpha software?” How could anyone think otherwise, maybe because 80% of the npm ecosystem seems to be 0.x packages, who knows? While I don’t think that the label reflects on the supreme quality of the language, for me it is clearly in public alpha. For one it’s been in pre-release 0.x since 2012 and every version has had breaking changes, sometimes very severe ones. Usually for a beta you consider the API mostly done and wait for clients to find the edge cases that are still lingering. But maybe that’s just me.
I don’t expect 1.0 to be on the horizon yet, Evan explicitly stated that he isn’t in a rush - “Get it right instead of getting it now”. This is the feature set I’m keeping in the back of my head.
My guess - based on the roadmap document - is that with 0.19 new use cases will open up and the community will start to experiment and I expect at least one minor correction/addition release to smooth out the edges of these. Maybe new use-cases will become obvious with that. So this’d be 0.20.
There are also a lot of Web APIs that are currently not directly supported but need to be integrated via ports, which might take another minor release to even out - maybe Elm doesn’t need more support for Web APIs? I personally am fine with the ports solution but I have a feeling that a lot of people might beg to differ. So kind of 0.21 - maybe not.
Rumor has it that the tool integration will be a priority in the future so some kind of language server integration might need another minor release - I’m not familiar enough with the elm-compiler to gauge whether this is necessary or already in place but I wouldn’t be surprised if this warranted a whole bag of workload that has typically been batched. So could be 0.22?
And then there’s also this interface/monad/implicit situation that is bothering people that might get addressed some day, maybe it won’t, so for good measure there’s at least one minor release. So potentially 0.23?
I think the availability of the planned integrated garbage collector for WebAssembly in the near future will attract a lot of attention to all sorts of “compile-to-js” languages, including Elm, of course. From a technical standpoint, if I were to implement the WebAssembly target I’d be darned sure that there will be no more hard breaking changes, so I put my baseline of 1.0 (maybe way) after that GC date availability. Seeing how there isn’t even a draft spec published as of today for that I wouldn’t hold my breath. I could be wrong and the code gen is in such good condition after the big 0.19 that adding WebAssembly before 1.0 might be an option, I don’t know.
1 Like
Cool, so 1.0 by 2030…
But to be serious. 1.0 does not mean no more breaking changes, you can always break and go to 2.0. I think 1.0 would mean its good enough to be considered ready, and worth putting in the effort to maintain and bug fix the release. You would not go to 1.0 if you are thinking of releasing 2.0 next week, but if it is going to live for a year or more then surely it is worth maintaining it?
1 Like
Off-topic: Not unless you’re called .NET Core 1.0 
- well at least 2.0 seems to be production ready…