Skip to content

doc/conf.py: if set, use SOURCE_DATE_EPOCH to set copyright year. #20608

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

vagrantc
Copy link
Contributor

@vagrantc vagrantc commented Jul 8, 2021

The build date of the software shouldn't really have any bearing on
the copyright dates, but by respecting SOURCE_DATE_EPOCH, it at least
limits this to the last time something in the source was changed.

https://reproducible-builds.org/specs/source-date-epoch/

PR Summary

PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

The build date of the software shouldn't really have any bearing on
the copyright dates, but by respecting SOURCE_DATE_EPOCH, it at least
limits this to the last time something in the source was changed.

https://reproducible-builds.org/specs/source-date-epoch/
@vagrantc
Copy link
Contributor Author

vagrantc commented Jul 8, 2021

originally reported as https://bugs.debian.org/990339

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for opening your first PR into Matplotlib!

If you have not heard from us in a while, please feel free to ping @matplotlib/developers or anyone who has commented on the PR. Most of our reviewers are volunteers and sometimes things fall through the cracks.

You can also join us on gitter for real-time discussion.

For details on testing, writing docs, and our review process, please see the developer guide

We strive to be a welcoming and open project. Please follow our Code of Conduct.

@jklymak
Copy link
Member

jklymak commented Jul 8, 2021

Is this really an issue? Matplotlib source changes a lot more often than yearly.

@QuLogic
Copy link
Member

QuLogic commented Jul 8, 2021

SOURCE_DATE_EPOCH is set in package builds to make things more reproducible; we also obey it for timestamps in e.g., PDF files.

This needs to pass flake8 though.

@vagrantc
Copy link
Contributor Author

Is this really an issue? Matplotlib source changes a lot more often than yearly.

One problem is if you build a version from 2019 in 2021, without changing anything in the source code, the documentation will incorrectly claim copyright for the year it was built(2021), not when the source was written(2019).

Another problem is if you build a version from 2019 in 2021, it will contain changes, even if you use the exact same toolchain for the two builds, so it is not bit-for-bit identical, requiring manual review of the differences rather than comparing for bit-for-bit identical files using a checksum.

Hope that helps explain it better!

@vagrantc
Copy link
Contributor Author

flake8 issue should be fixed now.

@jklymak jklymak merged commit 30cbdf7 into matplotlib:master Jul 10, 2021
@QuLogic QuLogic added this to the v3.5.0 milestone Jul 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants