dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Version Strings

Re: Version Strings

From: Torne Wuff <>
Date: Thu, 15 Jan 2009 11:16:38 +0000

On Thu, Jan 15 09 at 1:19:04AM -0500, Andrew Mahone wrote:
> For what it's worth, I don't favor changing any of what's currently in
> the version string, but I would consider extending it to be a good
> idea, provided that adding the commit-ish doesn't make it unreasonably
> long. I think the initial rNNNNNNN-DDDDDD should be extended with a
> -<extra>, which could include the git commit-ish if building from git,
> and perhaps just "-custom" if building from an svn checkout with local
> changes. I don't think adding the "-dirty" is very useful for git,
> since it doesn't let the developer who built it "find" those
> uncommitted changes - they may have since been committed, or edited
> further, but git can't tell you what commit object they might
> correspond to, so there's not really anything useful to say about
> them.

Possibly related: I use bzr-svn to branch the rockbox trunk, and have
modified the version script to produce something like
r19705+bzr19352-090108, where the rNNNNN number is the most recent
revision that has a svn revision number from trunk and the bzrNNNNN
number is the revision from my bzr branch. I quite like the format :)

I've not actually added -dirty to my script but have considered it.. it
doesn't tell you what/where the changes are, but it does tell you that
the code is not exactly as specified by the revision id, and thus that
issues may not be reproducable.

> There was also some talk on IRC about generating, and including in
> archive builds, a build-info.txt. This could contain a diff-stat for
> the changes vs svn, the git commit-ish if building from git, and
> whatever else might be helpful. Even if the commit-ish goes in an
> extra file, I'm still inclined to favor commit-ish in version string,
> because it allows a dev talking to a user with a test build to very
> easily get information about that test build from them, just by asking
> for the displayed version string. Assuming it's their build, or built
> from a public repository, they can then find the exact set of changes
> made to the svn revision on which the build was based.

That would be good, and something I'd adapt to support bzr :)

Torne Wuff
Received on 2009-01-15

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy