* Fix typo
* Lock file changes after running 'npm install --lockfile-version 1' w/ Node 14
* Format file prior to change
* Remove the html5shiv JS package & all references to it
* Remove the copy-webpack-plugin JS package as no longer used
---------
Co-authored-by: Manuel Kaufmann <humitos@gmail.com>
* Changelog for 1.2.2
* 1.2.2rc1
* Build: Fix bug that reads out container id from previous run
* Update package-lock to match release
* Bump to 1.2.2 final
* 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
* Update __init__.py because it wasn't updated by previous bump2version
* Add some comments about docker mechanisms that are disturbing release workflow
* Bump to version 1.1.0b3
* Revert "Bump to 1.1.0b2, rebuild assets"
This reverts commit 615eb528cc.
* Add changelog entry for #1073
* Changelog entry for #1193
* Bump to 1.1.0 using bump2version
* Use PEP440 and make it a beta, i.e. "1.1.0b1"
* Auto-generated package-lock.json but with version bumps
* Bump to 1.1.0b2, rebuild assets
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
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)
* Setup: Require docutils<0.17'
Docutils 0.17 changes some rendering of properties, until support is added we should probably pin to use an older version.
I may not be a bad idea to keep a pinned version in the theme to prevent this issue in the future.
* Release 0.5.2
Include a changelog and bump versions
* Fix changelog
Co-authored-by: Aaron Carlisle <carlisle.b3d@gmail.com>
* npm: Add a few missing package fields
This fixes these warnings when running `npm install`:
```
npm WARN sphinx_rtd_theme@0.5.1 No repository field.
npm WARN sphinx_rtd_theme@0.5.1 No license field.
```
* 0.5.2
* Revert version bump
* Revert version bump
This is a release candidate for 0.5.0, which adds support for both HTML4
and HTML5 writers, which should support the default writer regardless of
your version of Sphinx.
Also included in this release are localization efforts and 10 language
translations.
You will need to specify the release manually to test, if there are no
major issues, we will have a 0.5.0 release shortly.
Closes#886Closes#712
I moved the configuration to setup.cfg, with the rest of the tooling
configurations.
I had trouble getting the parsing to work for both the current pattern
that exists in this repository (`0.4.3.dev0`), and the pattern we use in
other repositories (`0.4.3alpha1` and `0.4.3rc1`).
The release pattern would potentially be:
* Version is `0.4.3alpha1`
* Bump to `0.5.0alpha1` or `0.5.0rc1` for testing release, `0.5.0` for
full release
* Commit, tag, etc the new release
* Release to PyPI
* Bump to `0.5.1alpha1` and commit. This is the next development release
that would be in `master` branch
