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)
This should'nt be a breaking change as backward compatibility is preserved so this change could go into 1.0 or wait until 1.1.
I know a lot of users are asking for this so it might be nice to include this in 1.0.
Fixes#1115
* 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>
Sphinx 1.6 is required for de76c03824 we also do not test against versions lower than 1.6 so we should safely drop it.
This is similar to #1076 and #1075 but less strict
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
This uses force mode to download po files, always. Normal operation is
to use the file modification date for comparison, which doesn't work
because of Git.
This also sets `onlyreviewed` mode, which will omit strings which are
not translated yet. This will result in the underlying source
translation being used in place, until the string is reviewed in
transifex.
The main change here is that we load information into the template so
that CSS can make decisions about what element hierarchy it can expect,
instead of covering both html4 and html5 writer with a single set of
rules. I also fixed the tox config so that it generates docs for
testing.
This is also in part going to revert the changes in #785. Instead of
maintaining a list of `dl` classes to apply the domain styles to, this
PR instead maintains a list of definition list classes to *not* apply
the domain definition list styling too. There are too many possibilities
to cover with an include list.
This is a POC that shows building webpack through standard `setup.py`
commands. Any call to `setup.py build` or `bdist` or `sdist` will
trigger a Webpack build of the assets first. A non-zero exit code will
halt the process.
Also, moved the `npm run dev` command, which here is `python setup.py
watch`, though there is perhaps something better here. There is already
`python setup.py develop`, which has a separate function, so I don't
want to collide there.
Example output here:
https://gist.github.com/agjohnson/cdaab364fe598daa7f3bef750cfb84dd
Refs #797
The fonts are in `static/fonts`, but setup.py has been installing
`static/font`. That didn't seem to work for me. This changes setup.py to
match the actual directory.
