Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#18224 closed Bug (fixed)

`django.utils.version.get_svn_revision` isn't appropriate anymore

Reported by: aaugustin Owned by: aaugustin
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

Description

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 aaugustin 3 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 years ago by aaugustin

  • Owner changed from nobody to aaugustin

Changed 3 years ago by aaugustin

comment:2 Changed 3 years ago by aaugustin

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 3 years ago by aaugustin

#18228 was a duplicate.

comment:4 Changed 3 years ago by pressureman

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 3 years ago by aaugustin

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

comment:6 Changed 3 years ago by pressureman

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 3 years ago by aaugustin

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 3 years ago by aaugustin

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

comment:9 Changed 3 years ago by pressureman

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