Code

Opened 6 months ago

Closed 4 months ago

#21400 closed Bug (fixed)

The downloadable documentation displays the wrong version

Reported by: bmispelon Owned by: nobody
Component: *.djangoproject.com Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

If you download the HTML documentation for the dev version [1], you'll see that the title (both <title> and <h1>) say "Django 1.5.4 documentation" instead of the correct version.
The same thing happens on the 1.6 version but not on the 1.4 one (unsurprisingly, the 1.5 version has the correct title too).

It seems that the content of the documentation corresponds to the right version and only the title is wrong.

This might be related to #20469.

[1] https://docs.djangoproject.com/m/docs/django-docs-dev-en.zip

Attachments (2)

21400.diff (1.1 KB) - added by claudep 6 months ago.
Getting VERSION from current tree
21400.2.diff (411 bytes) - added by timo 4 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 months ago by anonymous

Off the cuff guess... the build environment is incorrect. Ie, the sphinx build was fed 1.6 source code, but was told the documentation version is 1.5.4.

comment:2 Changed 6 months ago by claudep

Repeating my comment on the duplicate #21394:
"As I can see, this is not a problem with the documentation version itself, but simply with the version number in the title. It might be caused by the way the release variable is defined in docs/conf.py."

I guess the release variable depends on the current Python path, because of from django import VERSION (assuming there are several versions of Django on the build server). To prevent this, we might have to open the relative ../django/__init__.py file and eval its VERSION line.

Changed 6 months ago by claudep

Getting VERSION from current tree

comment:3 Changed 6 months ago by claudep

  • Has patch set

comment:4 Changed 4 months ago by timo

  • Patch needs improvement set

The patch doesn't work properly. For example, on the 1.6 branch, the VERSION is currently (1, 6, 2, 'alpha', 0) which cause the branch which returns pep386ver + '.dev' which is the version of Django we have on the server + '.dev'. We could continue to try to make this work, although it might be simpler just to revert this trick and the associated sys.path hack as I'm not sure it buys as a whole lot besides one less final to bump on each release:

373df56d36891b9ab1f88519bf9e8f3c0b3bb108
0b98ef632147a26f2430a3ede48d9e58983cc3ae

I'm going to leave a comment on Ramiro's original commit to get his input.

comment:5 Changed 4 months ago by ramiro

AFAICS the change (plus later fixups) is working (i.e doesn't show the wrong title) on:

For every Django doc version since 1.5 up to master.

I'd say the problem isn't with the code but rather with the docs build environment on our own servers (the ones in charge of creating the HTML tarball that shows the issue).

It's strange that the code works correctly even on external servers that use deployment/building/publishing techniques we don't have control over like the RTD ones.

Last edited 4 months ago by ramiro (previous) (diff)

comment:6 Changed 4 months ago by timo

  • Patch needs improvement unset

The documentation builds on our server use the update_docs management command so the first version of Django that's imported is whatever we have the site deployed with (currently 1.5.4 it seems). I believe we need to reload the Django module after modifying sys.path earlier in the file in order to avoid getting that cached version of Django. It seems to work locally for me. What do you think?

Changed 4 months ago by timo

comment:7 Changed 4 months ago by timo

Alternatively, we could revisit our approach of building all versions of the docs as part of one management command/Python process. See #20469 for another issue of state leaking between doc builds.

comment:8 Changed 4 months ago by ramiro

Tim, What do you think about this one instead? https://github.com/django/djangoproject.com/pull/70

comment:9 Changed 4 months ago by timo

  • Triage Stage changed from Accepted to Ready for checkin

Works for me locally, let's give it a try.

comment:10 Changed 4 months ago by timo

  • Resolution set to fixed
  • Status changed from new to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.