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 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 builds on top of #405, addressing the outstanding review feedback. It:
* Moves workflow to our standard Transifex workflow, drops recommendation for
running babel commands by hand
* Configures Transifex
* Moves all of the commands needed to maintain translations into Grunt
* Sets up docs for translation testing
* Covers installation in docs better
* Drops recommendation for installation through submodules
* Drops superfluous translation documentation
* Cleans up some of the code
* Updates a lot of related documentation
* Updates files at Transifex and brings in full translations back to the
translation files in the repository