status of mtl

[Edward Kmett]

We had just started work on a new release of the mtl, and transferring more of the control of it to the core libraries committee, right before the decision was made to rejigger the internals of the core libraries committee. That should still be the plan, its just that all the people involved are a bit distracted.

-Edward

> On Sep 25, 2021, at 9:24 AM, Keith <keith.wygant at gmail.com> wrote:
> 
> I have heard in the past that MTL's maintainers are very conservative about pushing out new releases, because so much of tho Haskell ecosystem needs to be updated and rebuilt when they do.
> But the backlash seems to be cramming as much as possible into new releases. This is not ideal but it is pragmatic.
> 
> Hopefully Ed K. or somebody can give you the real details.
> 
> -- Keith
> 
> Sent from my phone with K-9 Mail.
> 
> 
>> On 25 September 2021 11:42:38 UTC, Ben Franksen <ben.franksen at online.de> wrote:
>> I wanted to use the CPS version of RWST from transformers but the latest 
>> release of mtl (2.2.2) does not provide instances yet. Looking at the 
>> github repo I see that the missing instances were added two years ago, 
>> with no release since then. With all due respect to the maintainers and 
>> developers, this is disappointing.
>> 
>> The ticket for release 2.3 mentions the following TODO items:
>> 
>>   - Document AccumT and SelectT
>>   - MonadAccum (including documentation)
>>   - MonadSelect (including documentation)
>> 
>> These all concern new additions made in the last two years, some of them 
>> quite recent.
>> 
>> This style of package maintenance doesn't make sense to me. Why add new 
>> features before releasing what's been done years ago? Why accept patches 
>> with additional features in the mainline if they are apparently 
>> incomplete (e.g. missing documentation) if that blocks progress toward a 
>> release?
>> 
>> The obvious solution (need i spell it out?) is to move all new features 
>> that aren't mature yet to feature branches until they are ready for the 
>> mainline. Then take the work that is complete and release that. What's 
>> the big deal? Add a few lines to the changelog, bump the version number, 
>> upload, announce it on the mailing list. If you don't like to rebase the 
>> master branch, fork off a release branch at the appropriate point in the 
>> history and do the release on that branch, cherry-picking later patches 
>> from master as necessary. (Maintaining a release branch per major 
>> version bump is good practice anyway and requires only minimal extra work.)
>> 
>> Don't fall into the trap of the perfect becoming the enemy of the good. 
>> No release is perfect, nor does it have to be. You can always make patch 
>> releases. If you make a mistake and the release is broken, just mark it 
>> as such on hackage, so cabal won't pick it by default.
>> 
>> Needless to say, none of this is in any way new or original.
>> 
>> Cheers
>> Ben
>> -- 
>> I would rather have questions that cannot be answered, than answers that
>> cannot be questioned.  -- Richard Feynman
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210925/71c1adf2/attachment.html>