[Django] #21400: The downloadable documentation displays the wrong version
Django
-----------------------------------------------+------------------------
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Severity: Normal | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------------+------------------------
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
--
Ticket URL: <https://code.djangoproject.com/ticket/21400>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:1>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:2>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:3>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* needs_better_patch: 0 => 1
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:4>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by ramiro):
AFAICS the change (plus
[[https://github.com/django/django/commit/0b98ef632147a26f2430a3ede48d9e58983cc3ae|later]]
[[https://github.com/django/django/commit/f3a0ecc9ee0eae09d2c779a74b32cce7e38c1773|fixups]])
is working (i.e dowsn't sjow the wrong title) on:
- Local builds of the docs
- The ''Read The Docs'' build servers in all, its versions:
- HTML: ttps://django.readthedocs.org/
- ePub
- PDF
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).
Is strange that even the code works correctly on extenal servers that use
deployment/building/publishing techniques we don't have control over like
the RTD ones.
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:5>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* needs_better_patch: 1 => 0
Comment:
The documentation builds on our server use the
[https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:6>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:7>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by ramiro):
Tim, What do you think about this one instead?
https://github.com/django/djangoproject.com/pull/70
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:8>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: new
Component: *.djangoproject.com | Version: master
Keywords: | Triage Stage: Ready for
Has patch: 1 | checkin
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timo):
* stage: Accepted => Ready for checkin
Comment:
Works for me locally, let's give it a try.
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:9>
Django
Reporter: bmispelon | Owner: nobody
Type: Bug | Status: closed
Component: *.djangoproject.com | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
Has patch: 1 | checkin
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by timo):
* status: new => closed
* resolution: => fixed
Comment:
Fixed by
https://github.com/django/djangoproject.com/commit/e610d7bc74e7100561d648918bb83012d7fcd021
--
Ticket URL: <https://code.djangoproject.com/ticket/21400#comment:10>