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
I find it useful (as done in e.g. numpy) to have the version when things changed or were added in the narrative / API docs. E.g. in relevant places we would see a comment like "Default time scale for epoch times like J2000 changed from UTC to TT in version 3.2". The point being that the change log is not where most people wind up when learning about a function or method.
@mhvk points out this is done with a sphinx directive .. versionchanged: in numpy. Is that something astropy could just start using as a matter of policy?
EDIT by @pllim and @bsipocz : Preferably, this is to be done in small batches, like one PR for a single version release for a single subpackage. And only as far as as 2.0 and not earlier.
Yes please, I very much appreciate this info in the API docs, makes it so much easier to track down when something was introduced.
I would also suggest that adding this to the API docs retrospect this is an excellent package-novice issue implementation wise but a good way to get the to know the codebase and dev process.
At this point the package is large enough and there have been enough versions that we will probably need to find a way to automate this rather than doing by hand.
We do not assign issues. You are both free to contribute towards solving this one by opening pull requests, but I suggest you coordinate first to avoid repeated work. Thank you.
I wonder whether it would be worth approaching this from the point of view of trying to create a tool to automate this somewhat, or at the very least to validate any versionadded tags - because checking these manually is going to be difficult for reviewers.
Activity
bsipocz commentedon May 1, 2019
Yes please, I very much appreciate this info in the API docs, makes it so much easier to track down when something was introduced.
I would also suggest that adding this to the API docs retrospect this is an excellent
package-noviceissue implementation wise but a good way to get the to know the codebase and dev process.pllim commentedon May 2, 2019
bolt25 commentedon Feb 23, 2020
nikita-0209 commentedon Apr 30, 2020
mhvk commentedon Apr 30, 2020
bsipocz commentedon Apr 30, 2020
shubham00jain commentedon Oct 22, 2020
tactipus commentedon Aug 30, 2023
NathanMuniz18 commentedon Oct 19, 2024
astrofrog commentedon Oct 19, 2024
At this point the package is large enough and there have been enough versions that we will probably need to find a way to automate this rather than doing by hand.
NathanMuniz18 commentedon Oct 19, 2024
8 remaining items
LoveChauhan-18 commentedon Feb 7, 2026
neutrinoceros commentedon Feb 7, 2026
We do not assign issues. You are both free to contribute towards solving this one by opening pull requests, but I suggest you coordinate first to avoid repeated work. Thank you.
Pittu-Sharma commentedon Feb 13, 2026
LoveChauhan-18 commentedon Feb 13, 2026
shoaib-1122-tech commentedon Feb 25, 2026
astrofrog commentedon Feb 25, 2026
I wonder whether it would be worth approaching this from the point of view of trying to create a tool to automate this somewhat, or at the very least to validate any versionadded tags - because checking these manually is going to be difficult for reviewers.
pllim commentedon Feb 25, 2026
Maybe this is not really worth pursuing. Time is better spent on reviewing actual bug fixes. We will just have to remember to use this going forward.
luvyarana commentedon Mar 2, 2026
Thenewbiecoder80221 commentedon Mar 7, 2026