gh-pages issues about asciidoc-py HOT 7 CLOSED

I guess remove it for now and enable asciidoc.guthub.io/asciidoc-py3 for now?

As part of #9, I can also document setting up Travis to generate the HTML source and then push to gh-pages branch.

from asciidoc-py.

We really need a way of keeping the docs for this implementation separate from any pages that will be made for the language definition. If simply deleting the CNAME will allow docs for the implementation to be located in the gh-pages branch so its particular to this repository then that would be the best. Later CNAME may be added back and removed from the asciidoc-py2 repo.

For Travis, the problem is we don't want the docs pushed for every commit to a new PR, only on merged PRs, if it can do that should be fine, otherwise it needs to stay manual.

Also note that when a release happens there needs to be a way of keeping a set of docs that match the released version (until next release) separate from the development docs. Its a pity Read the Docs does only markdown and rest, @mojavelinux why havn't you got them using asciidoctor :)

from asciidoc-py.

It's possible to setup Travis to push to the gh-pages branch on any commit to any branch or PR, only commits to master, or just commits that get tagged, and anything in between. For now, I'll make a PR for it on to act on commits to master. It will require some minor action on your side to give Travis permission on GitHub to make the commits.

from asciidoc-py.

I think we need to open a new issue to decide how to handle asciidoc.org. In particular, how will the docs for Asciidoc Python 2 and 3 be handled? We need to think about this at a higher level than just deleting the CNAME. Let's think about what the URLs should be, then decide how to get there technically. We don't have to be locked into the default GitHub Pages workflow.

from asciidoc-py.

With #102 on the horizon which gives a nice path to automated generation of gh-pages (see #105) and https://asciidoc.github.io/asciidoc-py3 for result. There's still a bit of clean-up to be done, but for now, would it make sense to at least point https://asciidoc.org at the new python3 implementation and links for now, until a new site can be set-up at wherever that covers the asciidoc spec (when it's done in https://www.eclipse.org/org/workinggroups/asciidoc-charter.php or whatever?).

from asciidoc-py.

Also note that when a release happens there needs to be a way of keeping a set of docs that match the released version (until next release) separate from the development docs.

I've opened #106 to track this, with the idea of starting to do this from 9.0.0 onward.

from asciidoc-py.

Closing this as https://asciidoc.org now points at the asciidoc-py3 website, which is now automatically updated on pushes to master.

from asciidoc-py.