Which branches/tags are the matplotlib documentation released from, respectively?

Community
1

Hello, Matplotlib Team/Community.

After briefly reviewing the source code of the matplotlib repository, I have the following questions:

  1. Which branches/tags are the matplotlib documentation released from, respectively?
  2. Why are the v3.7.[n]-doc and v3.3.[n]-doc branches missing?
  3. What are the relationships/differences between the v3.8.4-doc and v3.8.x branches?
  4. Will the patch number of the v3.8.4-doc branch be updated (to v3.8.5-doc) if a new tag v3.8.5 is released?

Screenshot_20240407_181558
Screenshot_20240407_181558369×650 20.7 KB
Screenshot_20240407_182806
Screenshot_20240407_182806421×720 28.4 KB

2

The install version is from the relevant tag; the docs part is from the -doc branch. The exact commit is noted at the bottom of every page.

The doc branches are deleted once they are merged into the next release; only the last one for a vX.Y.* is kept.

See Pull request guidelines — Matplotlib 3.9.0.dev1544+ga7c32101c3 documentation

Yes.

3

Hello, @QuLogic

Thank for your replies. But I’m confused that:

If the v3.7.[n]-doc and v3.3.[n]-doc branches have been deleted, then from which branches are the documents for versions 3.7 and 3.3 built and published?

And how does Matplotlib’s CI/CD know which branches will be triggered to build the docs from their sources? For example, there are v3.6.3-doc and v3.6.x branches now. Where is the code that tells Matplotlib’s CI/CD to trigger the one to build and the other not to do so?

4

Branches are just pointers to commits; the published docs are built from the commit noted at the bottom of every page.

There is no CI for published documentation; it is produced by the release manager.

Only Matplotlib documentation — Matplotlib 3.9.0.dev1556+g91234e2362 documentation is automatically created from the main branch.

5

Theoretically, for versions other than the main branch, can we instead build the documentation targeting the corresponding highest version tag? For instance:

  • To build the documentation for version 3.9, checkout to the highest version tag v3.9.[n] and then build the documentation.
  • To build the documentation for version 3.8, checkout to the highest version tag v3.8.[n] and then build the documentation.
  • To build the documentation for version 3.7, checkout to the highest version tag v3.7.[n] and then build the documentation.
  • And so on.

This is similar to how the CMake documentation for version 3.x are built targeting specific tags.

The reason I’m asking this is to confirm the following:

Assuming the current 3.8.[n]-doc branch is 3.8.4-doc, then any RPs or changes merged into 3.8.4-doc will ultimately be included in the newly released v3.8.5 tag, right?

6

Sure, in most cases, they are nearly equivalent; the only thing missing from the -doc branch is the Zenodo DOI. Though the -doc branches do get subsequent backports, they are almost never rebuilt after that.