The first step towards Asciidoctor 1.6.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

The first step towards Asciidoctor 1.6.0

mojavelinux
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: The first step towards Asciidoctor 1.6.0

LightGuardjp
Sounds like we need a way to slurp code across git repos perhaps.  

On Thursday, November 26, 2015, mojavelinux [via Asciidoctor :: Discussion] <[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



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/The-first-step-towards-Asciidoctor-1-6-0-tp3977.html
To start a new topic under Asciidoctor :: Discussion, email <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ml-node%2Bs49171n1h37@n6.nabble.com&#39;);" target="_blank">ml-node+s49171n1h37@...
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML


--
Sent from Gmail Mobile
Reply | Threaded
Open this post in threaded view
|

Re: The first step towards Asciidoctor 1.6.0

mojavelinux
Administrator


Sounds like we need a way to slurp code across git repos perhaps. 

That's easy, just a matter of doing it.

-Dan


--
Dan Allen | @mojavelinux | http://google.com/profiles/dan.j.allen
Reply | Threaded
Open this post in threaded view
|

Re: The first step towards Asciidoctor 1.6.0

wolandscat
In reply to this post by mojavelinux
I would be very interested to put my 10p into the requests for change for 1.6.0, when a project plan is posted :)

I know everyone must have a giant list of things that need doing, but I like the idea of not allowing the minis to get stuck behind the Mack trucks. My Mack truck would be a proper system for doing Xrefs, built into Brackets or AsciidocFX. But I can think of a few minis as well, things that FrameMaker did that I think AD could be made to do sort of easily. I imagine that the Latex people here might have some similar thoughts based on their use of that power tool.

I wouldn't mind having a project tracker to post my Mack trucks and minis though! I'd be happy to make the effort to do some requirements and design work on the Xrefs and a couple of other big ones, if anyone is interested in that kind of contribution.

BTW, in openEHR, since we are an open source .org, we get to use Atlassian Jira On Demand for free. We rely on it for project management. Could this be of any interest to the Asciidoctor dev & test community? We have Problem Reports and Change Requests posted for the next 3 releases or so; pretty easy to manage in latest Jira.

- thomas
Reply | Threaded
Open this post in threaded view
|

Re: The first step towards Asciidoctor 1.6.0

mojavelinux
Administrator
Thomas,

(replies inline)

I would be very interested to put my 10p into the requests for change for 1.6.0, when a project plan is posted :)

And I would greatly value your input, which I'd argue is worth much more than 10p. We use the issue tracker to do project planning. Here's the current list for the 1.6.x series, though it's far from being curated at this point. Right now, everything is attached to 1.6.0, but we'll need to start breaking that out into point releases.


...of course, that also brings us to the versioning discussion. (See http://discuss.asciidoctor.org/Projects-versioning-strategy-td3841.html) I think to get versioning right, we need to go back to the planning. If we plan to put a bunch of features into a point release, then a bunch of features will end up in a point release. This may be the time to start following Breaking.Feature.Fix. Let's keep that discussion going on that other thread.
 

I know everyone must have a giant list of things that need doing, but I like the idea of not allowing the minis to get stuck behind the Mack trucks.

+1

I've always been in favor of not letting little things get stuck behind big things.


I wouldn't mind having a project tracker to post my Mack trucks and minis though!

Don't hold back from using the GitHub issue tracker. The closer this information is to the code, the better, IMO.


Activity drives movement.
 
I'd be happy to make the effort to do some requirements and design work on the Xrefs and a couple of other big ones, if anyone is interested in that kind of contribution.

Definitely. The hardest part about issue #858 is the design. Once we figure out how to declare this behavior in a way that is true to the AsciiDoc syntax and conventions (aka it feels right), then we'll be well on our way to getting it implemented.

If we need more space to design, then we can always use the wiki for longer proposals (archiving them when the discussion is over).

 

BTW, in openEHR, since we are an open source .org, we get to use Atlassian Jira On Demand for free. We rely on it for project management. Could this be of any interest to the Asciidoctor dev & test community? We have Problem Reports and Change Requests posted for the next 3 releases or so; pretty easy to manage in latest Jira.

I loath JIRA. Although the simplicity of the GitHub issue tracker is sometimes limiting, I find it to be extremely effective for keeping development moving. (username mentions, issue mentions, commit mentions, git integration, etc.)

There are interfaces that rest on top of the GitHub issue tracker like waffle.io. I sometimes use them, but I always come home to GitHub issue tracker in the end because it allows me to move so quickly.

-Dan

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