#18224 closed Bug (fixed)
`django.utils.version.get_svn_revision` isn't appropriate anymore
Reported by: | Aymeric Augustin | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
We're no longer using SVN.
Callers of this function, like django.get_version
, need to be updated.
Attachments (1)
Change History (10)
comment:1 by , 13 years ago
Owner: | changed from | to
---|
by , 13 years ago
Attachment: | 18224.patch added |
---|
comment:2 by , 13 years ago
comment:4 by , 13 years ago
Perhaps it might be a good idea to append the abbreviated commit hash to the date in the 'git show' command, eg
git show --pretty=format:%ct-%H --quiet HEAD
which yields an output like '1335619144-10cade8fac143984fc8416f3179c955e9f0c7f7b'. Github appears to use 10-digit abbreviated hashes, as opposed to Git's 7-digit ones. If the commit hash was shown in the version number, using the same format/length as Github, this would make it even easier to locate the commit. Also, if the commit hash is explicitly included in the version stamp, perhaps the timestamp could just be a Unix timestamp afterall.
comment:5 by , 13 years ago
Unfortunately we can't include the hash because the version number would no longer comply with PEP 386.
comment:6 by , 13 years ago
In that case the "devN" suffix becomes rather useless, or at the very least, quite inconvenient. Is it worth adding a separate function (not used to build the version stamp) which actually does return the Git commit hash?
comment:7 by , 13 years ago
If we don't include this suffix, all post-1.4 versions will be labeled 1.5, which is rather confusing. The suffix makes it clear that it's a development version.
Where would Django use a Python function returning the git commit hash?
comment:8 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in 02a5b41db4ff8544f93a5d9854b346a9aae4f556.
comment:9 by , 13 years ago
I didn't suggest not including the suffix. I suggested included a function to retrieve the git commit hash, for debugging purposes, to make it easy to locate the particular code revision now that Django is hosted on github.
Here's an in-place replacement for the existing functionality.
We can't use the SHA1 of the changeset because the identifier must be numeric.
We can use either a human readable timestamp (14 digits) or a Unix timestamp (10 digits). I implemented the first one, even though it's longer, because it will be easier to locate the corresponding changeset in GitHub (or any other git UI).