Put a tag from time to time to the Python Packaging User Guide?

[fconil]

hi,
I was wondering if you could put a tag from time to time on the Python Packaging User Guide.
May be a calendar versionning tag ?
It could enable going back and forth in the documentation on Read The Docs.
Thanks to the team

[willingc]

@fconil I think that would be a helpful thing to do. What do other folks think? Monthly might be a good cadence.

[willingc]

Related to #1390

[pradyunsg]

I'm not sure I understand why this is being requested. @fconil Could you clarify what use-case/problem this solves?

It could enable going back and forth in the documentation on Read The Docs.

Is there a specific reason you want to do this?

My concern with exposing multiple versions on RTD is that if we're doing tags regularly, there's going to be lots of pages with the same content on the domain and I'm mildly concerned about the SEO effects that'd have; the domain currently has decent SEO reputation and having duplicated content will make it difficult to ensure that it stays that way and that users are directed to the latest page as often as possible.

Certain things might be better covered via looking at the git history or us actually maintaining a proper changelog.

[fconil]

I am diving into packaging as I am asked some choices and advices on our project. I am trying to write what I have understood and the steps to follow.

I made some links to the documentation and I discovered Writing your pyproject.toml that I did not saw at the beginning.
So I was wondering when it was made and how I missed it. That's how I went to this repository and found this was a new page created this month. That why I thought a tag could be useful : these are the 2023 instructions, for example. It could help making a diff between two tags to know what was changed.

I also saw an issue (#1382) for moving a page I referenced, which is something that happen. I was reading a blog post on packaging history which had a broken link to distutils, knowing distutils has been removed in Python 3.12, I went to distutils (Python 3.11) page.

I have no knowledge on SEO problems. My issue is just a suggestion not a criticism, I thought it would be less work than a writing a changelog. If you don't find it useful, I learned how to diff with dates :)

[jeanas]

I also saw an issue (#1382) for moving a page I referenced, which is something that happen. I was reading a blog post on packaging history which had a broken link to distutils, knowing distutils has been removed in Python 3.12, I went to distutils (Python 3.11) page.

Note that (unlike the Python documentation) we always add redirects when moving or removing pages so that existing links do not break.

[sinoroc]

There is also this thread about adding some kind of changelog. Would that help?

I do not know if @fconil wants the older versions to be available as built and published pages, or if having the tags on the git repository would be enough.

there's going to be lots of pages with the same content on the domain and I'm mildly concerned about the SEO effects that'd have; the domain currently has decent SEO reputation and having duplicated content will make it difficult to ensure that it stays that way

What if the older versions are available only on a different domain (on readthedocs.org for example)? Is that possible? Would that be potentially less damaging from a SEO point of view?

All in all, I think there is some value in having some kind of history somewhere. But I do not know how to realize this. Changelog, keeping the old versions published, never delete pages (but only unlink them and mark them as deprecated)... all seem to have some cons that might be bigger than the pros.

[fconil]

I do not know if @fconil wants the older versions to be available as built and published pages, or if having the tags on the git repository would be enough.

Ideally, yes, I would like to read published pages for some points in time. That way, one can see "Ok this were the instructions 2 years ago but now it has changed".

[jeanas]

Ideally, yes, I would like to read published pages for some points in time. That way, one can see "Ok this were the instructions 2 years ago but now it has changed".

To be honest, there are instructions even today in the guide that could have been marked as no longer recommended five years ago (and it's already much better since the wave of contributions in the past few weeks) so I would not rely on this too much :)

[sinoroc]

I guess this also a solution: https://web.archive.org/web/20230000000000*/https://packaging.python.org/

[fconil]

I guess this also a solution: https://web.archive.org/web/20230000000000*/https://packaging.python.org/

It could be a workaround, but I prefer diff and blame.

I see nothing to add that could be useful to this discussion, should I close the issue or you prefer to do it ?

[pradyunsg]

I'll go ahead and close this out -- thanks for the suggestion!

---

For posterity, the way you can a date-based diff with the GitHub UI is to use Git's @{date} syntax for revision ranges. For example, below is a link to all commits since 2023-01-01:

https://github.com/pypa/packaging.python.org/compare/main@{2023-01-01}...main

Using the 3 dot syntax here shows all the commits on the GitHub.com UI as of the time of posting this comment.