The documentation pages explaining the roles of documentation components, modules, and families, and their relationship to Antora’s standardized directory structure have been extensively updated.

The component descriptor key-value pair examples have also been updated.

Most important of all, a huge thank you! to all the folks who helped make Antora even better.

When the site URL is set in the playbook using the site.url key or --url CLI option, it activates several additional features. Those features include the sitemap, the canonical URLs, and the 404 page. The site URL is also used when producing redirects. However, not all these features require an absolute URL. Some only require the pathname segment of the URL (the part after the domain name).

Therefore, Antora now allows you to set the site URL to a pathname. In that case, any feature that requires an absolute URL will remain disabled. Those features are the sitemap and the canonical URLs (as required by the powers that be). The 404 page will still be created (since it doesn’t need an absolute URL), and the pathname will also be used as the prefix for any paths in the redirect rules.

To summarize, the site URL can be either an absolute URL (with an optional pathname) or just a pathname. The playbook builder now validates that the site URL conforms to one of these two types.

The new key to control whether the git client automatically appends the .git suffix to the content source URL if missing was defined using camelCase, as in git.ensureGitSuffix. This naming is inconsistent with all other keys in the playbook schema. It should have been named git.ensure_git_suffix. As of this patch release, it now is. In other words:

The incorrect name is still supported, but should be considered deprecated.

When Antora reads files from a git tree, it does not assignment a timestamp to the file, meaning the mtime is undefined. That way, when the file is written, it gets assigned the current timestamp. At least, that’s how it’s supposed to work.

What the code was actually doing was assigning an invalid date. While this wasn’t a problem for the filesystem provider, it was for the archive provider. So all the files in the archive (ZIP) file that came from the git tree (and supplemental UI files that came from the playbook) had a timestamp of the Unix epoch (shortly after Woodstock). That caused certain cloud deployers to get rather confused (and dazed?). This patch release corrects this problem so that the timestamp of the files in the archive match the timestamp of the archive itself.

Antora 1.1 introduced the resource ID for referencing partial and example files stored in other modules, components, and versions. Now you can use the resource ID to reference images in the AsciiDoc image macro, too!

See Insert an Image for more image macro and resource ID examples. See Scheduled deprecations for Antora 3.0 for future image referencing changes.

You no longer have to store your images and attachments inside the assets folder. These folders can be top-level folders inside a module.

And don’t worry if you prefer using the assets folder or currently have files in an assets folder, Antora still collects images and attachments stored in the assets folder. See Documentation Components and Repositories and Modules, Families, and Subdirectories to learn more about how to organize your documentation source files.

The ability to use parent references in the target of the AsciiDoc image macro (e.g., image::../../../module-b/_images/image-filename.png[]) will be deprecated in Antora 3.0. You should begin replacing any such image targets with resource IDs.

Antora 1.1 reaches its end of life on August 31, 2019. If you’re using Antora 1.1, review the Antora 2.0 release notes and upgrade checklist before upgrading to the latest Antora release.