Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#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: master
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


We're no longer using SVN.

Callers of this function, like django.get_version, need to be updated.

Attachments (1)

18224.patch (4.0 KB) - added by Aymeric Augustin 5 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 years ago by Aymeric Augustin

Owner: changed from nobody to Aymeric Augustin

Changed 5 years ago by Aymeric Augustin

Attachment: 18224.patch added

comment:2 Changed 5 years ago by Aymeric Augustin

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).

comment:3 Changed 5 years ago by Aymeric Augustin

#18228 was a duplicate.

comment:4 Changed 5 years ago by Daniel Swarbrick

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 Changed 5 years ago by Aymeric Augustin

Unfortunately we can't include the hash because the version number would no longer comply with PEP 386.

comment:6 Changed 5 years ago by Daniel Swarbrick

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 Changed 4 years ago by Aymeric Augustin

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 Changed 4 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

comment:9 Changed 4 years ago by Daniel Swarbrick

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.

Note: See TracTickets for help on using tickets.
Back to Top