Version-lock unlocked dependencies #1759
Conversation
As the author of one of the new theme dependencies (`alabaster`), having a wholly unqualified requirement scared me a bit re: ability to make non-bugfix releases without downstream users' sites changing underneath them in unexpected (visual) ways without them consciously upgrading Sphinx versions. `alabaster` uses semantic versioning so the lock reflects this. For consistency, I also updated the other new theme dependency similarly, and made `babel` match its fellow non-theme dependencies in having an optimistic (vs semantic) version lock, but I can revert these changes if desired.
|
I should probably /cc @ericholscher since he manages PyPI for the other new theme :) |
|
+1 |
1 similar comment
|
+1 |
| 'sphinx_rtd_theme', | ||
| 'babel>=1.3', | ||
| 'alabaster>=0.7,<0.8', | ||
| 'sphinx_rtd_theme>=0.1,<0.2', |
There was a problem hiding this comment.
@ericholscher do you have a plan to release a new sphinx_rtd_theme in a day? Or do you have any opinion for about the version range 'sphinx_rtd_theme>=0.1,<0.2'?
|
That range sounds good. The theme is waiting on some work with the sass tooling. We can ship a new version next week, but no reason to wait for a release on it. |
|
@ericholscher Thanks! |
Version-lock unlocked dependencies
|
Thanks all |
|
Just pushed a 0.1.7 release of our theme, btw. Should be up to date with GH On Mon, Mar 9, 2015 at 1:02 PM, Jeff Forcier notifications@github.com
Eric Holscher |
|
Actually I see that 1.3 has a breaking theme change (tt -> code) -- I guess the correct thing to do is make the theme support both? I was thinking about making a version number to 0.2 to support the 1.3 release. Not sure what makes the most sense, I think I'll go with supporting both. |
|
Nice catch @ericholscher, I may need to make a related change in alabaster too (I see it styling |
|
Ah.. if sphinx_rtd_theme (and alabaster) update major version soon, I'll also update sphinx's setup.py before releasing. For now,I suspend releasing process. |
|
We can probably support both at the same time, in the same version, so no On Mon, Mar 9, 2015 at 4:37 PM, Takayuki SHIMIZUKAWA <
Eric Holscher |
|
@ericholscher I see. @bitprophet how about alabaster? |
|
I'll release 1.3 late today (UTC). |
|
@shimizukawa I consider such a change in alabaster to be a bugfix, so it wouldn't affect the Sphinx setup.py (i.e. I'd release 0.7.2, not 0.8). Please go ahead as needed :) |
|
Just pushed 0.7.2 with the changes re: tt/code, tests ok with one of my projects' API doc pages on both Sphinx 1.2 and Sphinx 1.3. Woo \o/ |
|
@bitprophet Thanks! I resume the release process. 😀 |
As the author of one of the new theme dependencies (
alabaster), having a wholly unqualified requirement scared me a bit re: ability to make non-bugfix releases without downstream users' sites changing underneath them in unexpected (visual) ways (without them consciously upgrading Sphinx versions).alabasteruses semantic versioning so the lock reflects this.For consistency, I updated the other new theme dependency similarly, and made
babelmatch its fellow non-theme dependencies in having an optimistic (vs semantic) version lock, but I can revert these changes if desired.