First stable release

[snoyberg]

I think we're at a point where we can make a first stable release of the library. I believe it should be versioned at 0.1.0.0, and the goal will be to avoid breaking changes from that point onward. (All releases to date have been marked as experimental and have massively broken the API.)

I'm opening this issue to alert people about this, and give everyone a chance to get some PRs in. I believe we need to resolve the following issues before a release:

• Qualified imports proposal #12 (qualified imports): it looks like the short names overall is more popular, so this is mostly a matter of updating the relevant modules with the right documentation
• Add trace functions #31 (trace functions): the biggest issue here is figuring out what the type of these functions should be (String, Text, etc)
• Remove partial functions from reexports #43 (remove partial functions): I'm not convinced we'll have a complete removal of all partial functions, but there is likely some low-hanging fruit to attack, like head, tail, etc
• A better Display typeclass #51 (better Display typeclass)

Post release, I'd like to create a Stack template for rio.

[akhra]

Your call on whether we stick with raw democracy on the import names, but I'm going to voice my view that it's worth looking at motivation as well. I expect favor for very short names to be partly composed of inertia, and since this is just a style guide feature (nobody's existing or future code will ever be broken by the import names Rio recommends), I feel it may be worth bucking tradition if all the direct Rio contributors agree that something more explicit is better practice. Bottom line, users who actively despise our choices will just stick with their own; we might as well aim for improvement otherwise.

BTW a branch of this topic is, do we also suggest unqualified imports for infix operators?

[snoyberg]

We're explicitly calling out a goal of standardizing current best practices in rio, not establishing new ones, if at all possible.

…

On Sat, Mar 3, 2018, 2:30 AM Theodore Lief Gannon ***@***.***> wrote: Your call on whether we stick with raw democracy on the import names, but I'm going to voice my view that it's worth looking at motivation as well. I expect favor for very short names to be partly composed of inertia, and since this is just a style guide feature (nobody's existing or future code will ever be broken by the import names Rio recommends), I feel it may be worth bucking tradition if all the direct Rio contributors agree that something more explicit is better practice. Bottom line, users who actively despise our choices will just stick with their own; we might as well aim for improvement otherwise. BTW a branch of this topic is, do we also suggest unqualified imports for infix operators? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBB8enRlme340VRN_306dXd-Xf5LZlks5taeQkgaJpZM4SZ6kK> .

[akhra]

Fair enough, and I suppose the only competing proposal which approaches "standard" level is full qualification, which I think the majority will rebel against. Including me, TBH. :) I'll bring up infix on #12.

[snoyberg]

I think that's it for the first stable release. If anyone has anything else they think needs to be addressed, now's the time to bring it up!

[mgsloan]

• Hide RIO.Prelude.* modules #72
• Remove stack-specific unicode logic from RIO.Prelude.Logger #73
• Prune some UnliftIO re-exports #78

Not as important but good to consider before the release:

• Remove stripCR function #74
• Remove some Data.Monoid wrappers #75

[snoyberg]

Alright, all blockers are resolved, I'll be making a release soon.