[neomutt-devel] frequency of releases, proceedings on refactoring the code

Darshit Shah darnir at gmail.com
Fri Jun 16 14:03:07 CEST 2017

On 15 June 2017 at 17:44, <toogley at mailbox.org> wrote:

> Hey List,
> on IRC, a discussion occured, which i want to move to the mailinglist to
> include more people. (and archive the discussion)
> To sum up my position:
> * i got the impression that we make very high stability/bugfree
>   guarantees. I think that doesn't work with mutt being so
>   complicated.
>   That only works when mutt is very much refactored, to a point where
>   necessary refactorings are very small.
> While I agree that refactoring is an inherently brittle process and the
Mutt codebase is far from being clean, I think NeoMutt must continue to
provide the stability guarantees.
Maybe have long testing releases which will hopefully be picked up by some

The main reason for this is that multiple distros have been providing
NeoMutt as Mutt and people tend to have an expectation of stability with
software they've been using for a few years now. We can't abruptly break
that expectation on a whim.

> * Because mutt is so complicated, i don't think we can avoid breaking
>   things. Of course we need to fix those bugs, but i think we need break
>   things in order to move forward effectively.
>   As far as i understand, @dkc disagreed with this idea.

I disagree with such breakages as well. You will only push people away from
using Neomutt in that fashion. Such breaking changes in a software that is
used on a daily basis is bad idea. Don't test your user's patience.

> * Because we can only make realistic stability/bugfree guarantees when
>   big parts of mutt are refactored, we should only then make the next
>   stable release. @flatcap agreed with this idea.
I agree that the next stable release should only be made when things are,
umm.. "Stable". Till then, there should be a few alpha releases for people
to try out. On Arch, many use the git version itself, updating from the
repository every couple of days. The master branch should not break as far
as possible.

Thanking You,
Darshit Shah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/attachments/20170616/86a65a1b/attachment.html>

More information about the neomutt-devel mailing list