Difference between revisions of "Completed: Proposal sha.txt"

From Audacity Wiki
Jump to: navigation, search
m (Galeandrews moved page Proposal sha.txt to Completed: Proposal sha.txt without leaving a redirect: Proposal implemented.)
Line 32: Line 32:
== Developer Backing ==
== Developer Backing ==
* James Crook
* James Crook
[[Category:Proposals Completed or Withdrawn]]

Revision as of 09:37, 18 May 2015

Proposal pages help us get from feature requests into actual plans. This proposal page is about conditionally showing more build information for QA in the build info window. Specifically it is to show what source revision the build was made from.

This solution is now employed by the Windows, OS X and Travis (Linux Ubuntu) alpha builds. However the Travis builds are not made available for download.

Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.

  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.


Gale has suggested that it would be really valuable to QA to have revision numbers actually in the builds and shown as part of the build info. That way even builds made on the same day from different source can be distinguished. It makes it easy to find what code from SVN was compiled to make that build, what changes are believed to be in, and what changes are not believed to be in. That is all vital information for QA.

Most end users don't care about revision number, so it could be argued that an actual release should not display the revision number. As we transition to Git, and with revision number like 26daea02e40796982c07b5b3f9f3cb752d54da69 it becomes even less likely that we might want to show that 'revision number' to most users. And there could also be extra work, if we build audacity RC2 and show say 'Audacity RC2' in the build info window, and now want to release it as an actual release, maybe we need to build again code that has been through test? Making it no longer tested? Oops.

Proposed Feature

A script run at build time ensures a line with a 7 digit short SHA linking to the commit log is present in the build info window.

We don't worry about users being put off by a 7 digit SHA, it's in the build info window after all, and the full sha is available. The flexibility to change the string after build e.g. from RC2 to 'Actual Release' without affecting the exe is not needed.


The script contains the following line:

git show -s --format="wxT(\"<a href=\\\"http://github.com/audacity/audacity/commit/%H\\\">%h</a> of %cd\")" > ./src/RevisionIdent.h

This overwrites an existing default version of the file, which says "No revision identifier was provided", with this line:

wxT("<a href=\"http://github.com/audacity/audacity/commit/fe8d3535d8feb212f04bc3750a0aed77ea72f1c0\">fe8d353</a> of Thu Apr 9 10:59:42 2015 +0100\")

This in turn in the HTML display becomes:

Commit Id:        fe8d353 of Thu Apr 9 10:59:42 2015 +0100

Where fe8d353 is hyperlinked to the commit. Note that we don't use the actual address https://github.com/audacity/audacity/<commit number> because the https:// link does not work in the About dialog.

Developer Backing

  • James Crook