Build number policy

[AntoineTurmel]

I was wondering if we should keep the build number... it's not really useful in my opinion since you can check version + date already...

Buildnumber was used on Songbird and incremented at each commit (if I remember well), and we don't really do so.

[mook]

The build number was incremented as part of the build process (in buildbot,
not in normal offline/developer builds). That was useful when you have
multiple build per day (e.g. spinning out RCs in preparation for a release).

For reference, Komodo currently uses the subversion revision number, since
that atomically increases automatically. In the git world, git describe
might be a good alternative. Of course, these two methods lose the ability
to differentiate builds using the same source (e.g., different dependency
binaries or build process changes). At this point, though, actually getting
builds might be higher priority.

[ilikenwf]

I'd be one to vote for using git describe...it's what I'm using for the versioning on the Archlinux PKGBUILD.

[rsjtdrjgfuzkfg]

Agree on the git describe for the buildnumber.

[rsjtdrjgfuzkfg]

#334 -- not sure if one can pull-request on an existing issue. If that is possible, I successfully failed to do that.

[freaktechnik]

No, you can't. You could make github corss refer to the issue by mentioning it in the pull's description, like it did for the commit. I'm also wondering if this kind of mention in the commit will auto-fix this bug as soon as it's merged.

[freaktechnik]

As I commented in #334:

Should we check for git's presence if --enable-official or --enable-nightly is set?

[rsjtdrjgfuzkfg]

@freaktechnik probably a good idea, if you know a fail-safe way to do that cross-platform? I'm not too sure what's possible in all shells used to build Nightingale. But it is not really bad if we don't imho.