[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
unclear.
> 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
(hopefully).
* 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