You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decide on policy for supporting Sphinx versions #85
It would be good to decide on some kind of policy for supporting Sphinx versions, since we currently support 1.3 and above which is quite ancient now (and this comes at the cost of more CI time). I'd like to propose a time-based window of 2 years for support. The oldest release in the last two years is 1.6.3 so we could e.g. support >=1.6, which seems reasonable?
Yeah, I agree with @bsipocz that >=1.7 makes sense. I worry a lot less about these things for the docs builds since that's not really so much of a "user" activity in most cases.
I think it's reasonable to say the policy something like "2 year time window, unless there's a specific good reason for being more agreessive", and InheritDocstrings I'd say counts as a "good reason".
Activity
bsipocz commentedon Aug 9, 2019
>=1.6seems more than reasonable, I would even argue for>=1.7, so InheritDocstrings can be assumed to work everywhere.astrofrog commentedon Aug 9, 2019
Happy to require 1.7, the first major release in the last two years.
astrofrog commentedon Aug 10, 2019
For the record, sphinx-astropy requires Sphinx 1.7 and later, and numpydoc requires Sphinx 1.6 and later.
eteq commentedon Aug 12, 2019
Yeah, I agree with @bsipocz that
>=1.7makes sense. I worry a lot less about these things for the docs builds since that's not really so much of a "user" activity in most cases.I think it's reasonable to say the policy something like "2 year time window, unless there's a specific good reason for being more agreessive", and
InheritDocstringsI'd say counts as a "good reason".