From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id b19b6dd7 for ; Sun, 2 Apr 2017 07:57:43 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1cuf4f-0007sV-Ni for discuss@mdocml.bsd.lv; Sun, 02 Apr 2017 14:57:42 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1cuf4e-0000iQ-Cr for discuss@mdocml.bsd.lv; Sun, 02 Apr 2017 14:57:40 +0200 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1cuf4e-0002CY-8g for discuss@mdocml.bsd.lv; Sun, 02 Apr 2017 14:57:40 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 8e1c4d3b for ; Sun, 2 Apr 2017 14:57:40 +0200 (CEST) Date: Sun, 2 Apr 2017 14:57:40 +0200 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: mandoc 1.13.x end of life Message-ID: <20170402125740.GB79932@athene.usta.de> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.2 (2016-07-01) Hi, i'm officially declaring the mandoc-1.13 branch obsolete. There was no feedback whatsoever regarding the 1.13.5 release candidate, and FreeBSD-stable made the explicit decision to migrate to mandoc-1.14 (thanks to Baptiste Daroussin for volunteering to move that project forward). So given the lack of interest, maintaining the 1.13 branch would seem like a waste of time. All systems still using mandoc-1.13.4 or even older releases are encouraged to upgrade to mandoc-1.14.1. Regarding the mid-term future of mandoc, i'm likely to - continue the parser reorganization, making even better low level roff(7) support possible in the long term - strengthen the four-layer architecture (parsers, state engines, validators, formatters) by moving duplicate code from the formatters to the state engines, and maybe some additional bits to the validators - unify the hash tables - maybe simplify some data structures - probably start making some invariants explicit - improve regression test coverage So for some time, the focus is likely to be on code quality rather than on features. Of course that doesn't exclude closing feature gaps when important ones are found. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv