Re: [PATCH v2 0/2] asciidoctor-extensions: provide `<refmiscinfo/>`

["Martin Ågren" <martin.agren@gmail.com>]

On Sat, 7 Sep 2019 at 08:45, Jeff King <peff@peff.net> wrote:
>
> On Thu, Sep 05, 2019 at 09:35:10PM +0200, Martin Ågren wrote:
>
> > > Yeah, I do still like that as an endgame, but I like what you have here
> > > as an intermediate step in the right direction.
> >
> > Hmm, so this sounds like once I am happy with replacing AsciiDoc with
> > Asciidoctor 1(.5.5), I should rather not propose a series "let's default
> > to Asciidoctor!!!" but instead a slightly more careful "go with
> > Asciidoctor, but document that we work badly with v2 and that the 2nd
> > choice after Asciidoctor 1 should be AsciiDoc". Or do you see it
> > differently? (I wonder which Asciidoctor-version Junio would be on..)
>
> Yeah, that seems reasonable.
>
> TBH, if making things in the middle step work turns out to be too hard,
> I'm not entirely opposed to a hard switch.
>
> The "does not work with 2.0" thing has to be a temporary step, though, I
> think, since using the older versions will get harder and harder as time
> goes on. I think it's OK to take such a temporary step as long as we
> understand where it leads (and presumably its to directly generating the
> roff with asciidoctor). The middle step of having asciidoctor+xmlto
> helps us understand and isolate which changes are responsible for which
> parts of the output.

So of these steps:

  0. Get Asciidoctor (v1) in shape.

  1. Switch the default to Asciidoctor (v1).

  2. Drop AsciiDoc to have faster Asciidoctor-processing, avoid xmlto
     and support Asciidoctor 2. And to avoid the Python 2 EOL, too.

Step 0 is not far away, so step 1 could be done fairly soon IMHO. Step 2
would "hopefully" happen soon after -- maybe even in the same release
cycle as step 1, and if not the same then the one just after. But I
might be the wrong person to trust on that one. I currently don't even
try to build with Asciidoctor 2. I might perhaps look into installing
it, but it could also be that I'll only start using it when it happens
to arrive through my distro.

So as long as I'm not looking into Asciidoctor 2, maybe I shouldn't be
the one to impose "default to asciidoctor" on the world. Dunno. In any
case, I should be able to bring the asciidoc/tor1 differences to a state
where we trust asciidoctor 1 to be in a good shape, so that "someone
else" could pick up the ball and work on asciidoctor 2 vs 1, knowing
that it's ok if they regress AsciiDoc support or even drop it entirely
in the process.

Martin