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

toogley at mailbox.org toogley at mailbox.org
Fri Jun 16 17:36:06 CEST 2017

On Fri 16 Jun 2017, 14:03:07 CEST, darnir at gmail.com wrote:
> Mutt codebase is far from being clean, I think NeoMutt must continue to
> provide the stability guarantees.

I agree with that. Of course - but only for stable releases. not at all
for devel releases. well, that is the current state - therefore i don't
want to radically change the stability guarantees. Sorry for being so

> 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.

Okay, that seems sensible. My suggestion for that is that master should
stay at it is at the moment. There should only be bugfixes merged in.
Therefore, neomutt-git in Arch is basically the same as the neomutt
package in arch.

Basically, my idea for the future developemnt is:

* We create a devel branch. There, we do heavy refactorings.
    * that will break things, but i think fixing the design is more
      important in this stage than fixing bugs. (for the devel branch)
    * After we fixed the design of mutt, we fix the bugs.
    * After that, we ask for heavy testing + fix reported bugs.
    * After that, we release a stable version
    * At this stage, the stability of mutt will be much better
    * I think, we will need longer than 1 year to do the refactoring,
      and until we can release the next stable version.
    * That means, the breakage i suggest doesn't happen on stable
      releases or on the master branch
    * I think this makes refactoring mutt's source code easier.

More information about the neomutt-devel mailing list