* Drop development version header from changelog
This makes just as much sense as a point release header, and won't
require any special attention when we're cutting a release.
* Bump release 1.2.0
* Update package lock
* Add docutils 0.18 citation/footnote support using CSS grid
This is a fix for #1322 that continues our pattern for HTML5 support
using CSS grids, introduced for support for docutils < 0.17 HTML5
support.
* Add lots of backreferences to a footnote
* Drop brackets from footnote/citation links
The brackets seem to be another docutils addition.
* Tune grid display for Sphinx 4 and 5
Backrefs have a new styling that drops a lot of punctuation
* Bump dependency on docutils to < 0.19
* Small tweak to footnote backrefs row span
We don't want to use too large a value here, as some browsers might make
explicit rows for us. We can't target -1 because the row count is
implicit.
* Revert some new styling and use nonbreaking backrefs for now
* Downgrade tox
* Use before pseudo class to break up backrefs consistently
This matches the version number in the Python package, and allows
bumpversion to continue working. We can revisit changing this version
later, but currently this version will never be updated again, as
bumpversion will not match this string anymore.
Fixes#1326
Perhaps this is a feature of Sphinx I'm not aware of, but using a
version number as the section label resulted in ``#id1`` instead.
I tried autosectionlabel, but as expected there were a lot of errors and
I don't feel it's worthwhile to spend time fixing them right now.
If we want the Readme to have more links, this breaks linking at the
index page in the built documentation. The version is hardcoded in links
in the readme version, and hardcoded links point to the wrong version in
the documentaiton
This finally defines our supported browsers and dependencies publicly,
and communicates our next several versions that we have planned so far.
This information is starting with 1.0.0, but I did try to capture some
historical information as well.
Because of the additional strings, translation percentage dropped. This
bumps that percentage down a bit, but I also ran with --minimum-perc 70
to get Polish locale as well.
Translators pointed out how the ARIA labels weren't descriptive,
especially because the translators don't have the same context around
the strings and HTML structure.
I added some translator context, so transifex can at least describe what
the string is used for, but also updated some of the strings to be more
descriptive. I dropped "breadcrumb" because it's colloquial language
that almost certainly won't translate well.
I think we talked about this and never followed through on the next few
release, not sure though. After we release a new version, I think we should be updating
the repository version to something other than the most current release.
The effect would be that the version in the repository would be an
alpha/dev release, and so would be possible to differentiate easily
between 0.5.2 release on PyPI and 0.5.3alpha1 development release from Git.
Right now, we don't follow up with incrementing this version, and so
it's harder to tell the difference. This is mostly for our use in
development.
It adds a small bit of overhead, but is nice and explicit.
This PR updates the version in the repository to 1.0.0alpha1. If we had
adopted this workflow, the progression would have been:
* Release 0.5.2, open PR bumping to 0.5.2 (run `bump2version release` and open PR)
* Follow up 0.5.2 release by bumping to `0.5.3alpha1` (run `bump2version patch` and open PR)
* We add a new feature, bump to `0.6.0alpha1` (run `bump2version minor` and open PR)
* Oops, backwards incompatible change. We bump to `1.0.0alpha1` (run `bump2version major` and open PR)
* We're ready for an rc, bump to `1.0.0rc1` (run `bump2version release` and open PR)
* Maybe we cut another rc after some fixes
* We're ready for final release, bump to `1.0.0` (run `bump2version release` and open PR)
* Follow up the release PR by bumping to the next version (run `bump2version patch` and open PR)
* Adds support for explicit tox environments for html4/5
* Adds utility factors for py2/3, for easy access to the system python3
binary
* Adds a noop -qa postfix factor to make it easy to compare against
master or a tag
Many of our PRs have out of date assets, making it hard to test the
latest changes. This will at least throw an error on the PR when build
assets aren't updated.
Many of our PRs have out of date assets, making it hard to test the
latest changes. This will at least throw an error on the PR when build
assets aren't updated.
Anthony