Re: The first step towards Asciidoctor 1.6.0

I haven't made this switch yet. Several bugs have cropped up in 1.5.3, so I've been working on fixing those. We're getting pretty close to needing a 1.5.4 release now, probably next week-ish. When that is done, I'll switch master to 1.6.0.

Cheers,

-Dan

On Thu, Nov 26, 2015 at 12:37 PM, Dan Allen <[hidden email]> wrote:

Now that we've made it beyond the 1.5.3 release, it's time to start taking steps towards Asciidoctor 1.6.0 (before we get stuck in another 1.5.x release cycle). Here's the plan. I'm going to make a branch for 1.5.x (in case we need to make other micro releases) and transition master to 1.6.x. I'll then shift around issues in the issue tracker accordingly so that we can start forming a picture of what 1.6.0 will include. Project management will be needed :)

It's important to note that 1.6.0 will not include the inline parser (https://github.com/asciidoctor/asciidoctor/issues/61). Instead, that is planned for Asciidoctor 2.0. That doesn't mean it will take any longer to implement, it just gives us an opportunity to make more releases in the interim. (Small things should not get stuck behind big things, as one manager of mine used to say).

Asciidoctor 1.6.0 is going to leave support for Ruby 1.8 behind and switch to using the more modern Ruby syntax (particularly for hashes). We may even drop Ruby 1.9 too, but I haven't made that call yet.

I do plan to make a very minor 1.5.4 release to address at least one regression in 1.5.3 and merge some pull requests that got left behind. But the focus of development should definitely be on Asciidoctor 1.6.0.

We also want to solve (or, at least start to solve) the docs problem in 1.6.0. What I mean is that we want to get the user manual out of the website and into a dedicated repository (that the website can consume). That way, we can start using branches in the documentation repository to align the documentation with releases of the code. We thought about putting the documentation directly in the code repository, but I think that mixes responsibilities too much and doesn't give us the flexibility to target docs changes against a (fixed) release. Repositories are cheap, so I think it's best if we use dedicated spaces. (In the end, experience will teach us what the right approach is).

Asciidoctor 1.6.0, here we come! Feedback welcome.

Cheers,

-Dan

--

Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen

... [show rest of quote]

--

Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen