Okay to do a 3.0.1 release of core with documentation fixes?
Janis Voigtländer
Since the release of core-3.0.0, some documentation fixes have accumulated, but are not visible on the package site. Some of these improvements could forestall questions that are coming up on the elm-discuss list. (Also, I have a bunch of students who are doing their term projects using Elm right now, so are looking at this documentation every day.)
It would be nice to release the documentation fixes to the package site. It would be strictly a PATCH release (elm-package diff is saying so), in fact there are only changes to the documentation, nothing changed in code. So no possible regressions.
Since I have write access to the repository, I could tag and publish a 3.0.1, but obviously I don’t want to do that without consent. Evan?
As a summary, the changes that would differentiate 3.0.1 from 3.0.0 can be seen in this GitHub view:
https://github.com/elm-lang/core/compare/3.0.0...master
Let me add that I would be more thrilled to have an actual bugfix release (which would still be 3.0.1, since only PATCH changes involved), including as many as possible of the following pull requests:
https://github.com/elm-lang/core/pull/183
https://github.com/elm-lang/core/pull/222
https://github.com/elm-lang/core/pull/294
https://github.com/elm-lang/core/pull/442
https://github.com/elm-lang/core/pull/463
But I don’t have my hopes high on that.
Daniel Bachler
I really like elm but the average time it takes for bugfix PRs to get merged is not great. IMHO this is bad both because people will be bitten by these bugs even though a solution already exists in the form of a PR and also because it discourages contributors.
There are also some PRs that suggest temporary solutions to existing problems, like e.g. https://github.com/elm-lang/core/pull/286 . I appreciate that the spirit of Elm is to prefer well thought out solutions over quick fixes, but it seems to me that there are several cases where opportunities to make the edges of Elm a little less sharp are disregarded in favour of some future general improvement. Maybe there can be a mechanism where temporary improvements can be linked back to big improvement tickets so they can be reverted if necessary once those features are implemented?
Max Goldstein
Janis Voigtländer
Let me add that I would be more thrilled to have an actual bugfix release (which would still be
3.0.1, since only PATCH changes involved), including as many as possible of the following pull requests:https://github.com/elm-lang/core/pull/183
https://github.com/elm-lang/core/pull/222
https://github.com/elm-lang/core/pull/294
https://github.com/elm-lang/core/pull/442
https://github.com/elm-lang/core/pull/463
Adding https://github.com/elm-lang/core/pull/342 to that list.
Janis Voigtländer
Let me add that I would be more thrilled to have an actual bugfix release (which would still be 3.0.1, since only PATCH changes involved), including as many as possible of the following pull requests:
https://github.com/elm-lang/core/pull/183
https://github.com/elm-lang/core/pull/222
https://github.com/elm-lang/core/pull/294
https://github.com/elm-lang/core/pull/442
https://github.com/elm-lang/core/pull/463Adding https://github.com/elm-lang/core/pull/342 to that list.
And https://github.com/elm-lang/core/pull/491, since the issue that addresses seems to prevent a person from using Elm in production right now.
Janis Voigtländer
Let me add that I would be more thrilled to have an actual bugfix release (which would still be 3.0.1, since only PATCH changes involved), including as many as possible of the following pull requests:
https://github.com/elm-lang/core/pull/183
https://github.com/elm-lang/core/pull/222
https://github.com/elm-lang/core/pull/294
https://github.com/elm-lang/core/pull/442
https://github.com/elm-lang/core/pull/463Adding https://github.com/elm-lang/core/pull/342 to that list.
And https://github.com/elm-lang/core/pull/491, since the issue that addresses seems to prevent a person from using Elm in production right now.