Skip to content

Add version changed for API changes #8651

Closed

Description

@taldcroft

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?

(This was a by-product of discussion in #8600).

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.

Activity

  1. bsipocz commented on May 1, 2019

    @bsipocz
    Member

    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.

  2. pllim commented on May 2, 2019

    @pllim
  3. bolt25 commented on Feb 23, 2020

    @bolt25
  4. nikita-0209 commented on Apr 30, 2020

    @nikita-0209
  5. mhvk commented on Apr 30, 2020

    @mhvk
  6. bsipocz commented on Apr 30, 2020

    @bsipocz
  7. shubham00jain commented on Oct 22, 2020

    @shubham00jain
  8. tactipus commented on Aug 30, 2023

    @tactipus
  9. NathanMuniz18 commented on Oct 19, 2024

    @NathanMuniz18
  10. astrofrog commented on Oct 19, 2024

    @astrofrog
    Member

    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.

  11. NathanMuniz18 commented on Oct 19, 2024

    @NathanMuniz18
  12. 8 remaining items

  13. LoveChauhan-18 commented on Feb 7, 2026

    @LoveChauhan-18
  14. neutrinoceros commented on Feb 7, 2026

    @neutrinoceros
    Contributor

    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.

  15. Pittu-Sharma commented on Feb 13, 2026

    @Pittu-Sharma
  16. LoveChauhan-18 commented on Feb 13, 2026

    @LoveChauhan-18
  17. shoaib-1122-tech commented on Feb 25, 2026

    @shoaib-1122-tech
  18. astrofrog commented on Feb 25, 2026

    @astrofrog
    Member

    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.

  19. pllim commented on Feb 25, 2026

    @pllim
    Member

    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.

  20. luvyarana commented on Mar 2, 2026

    @luvyarana
  21. Thenewbiecoder80221 commented on Mar 7, 2026

    @Thenewbiecoder80221
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions