Bug #6296

Changes to the build system

Added by planetmaker about 6 years ago.

Status:NewStart date:2013-08-22
Priority:NormalDue date:
Assignee:EyeMWing% Done:

0%

Category:-
Target version:-

Description

We're planning to change the build system on the DevZone. Further, distributed VCS allow only poorly to uniquely associate a numerical number with single commits, but rather they have a unique hash associated with them. Changing DevZone's CF, both viable alternatives for the build service only pull the required branch of a repository, so the current scheme to rely on the number the commit has in the central repository will fail.

(For simplicity's sake I copy the text from FIRS here. I suggest changes to the Makefile of FIRS which modifies displayed version and the NewGRF version (internally reported to OpenTTD):
displayed for releases: "FIRS Industry Replacement Set 1.4.0" (unchanged)
displayed for nightlies: "FIRS Industry Replacement Set 2013-08-22 (5aebe60e17b3)"
displayed for push: "FIRS Industry Replacement Set 2013-08-22 (5aebe60e17b3)"
Internal version: 4982 or 332662 (depending on branch number, see below).

The internal version increases by one every 24 hours. It's calculated as (branch number * 65536) + (day_of_commit - 1.1.2000).
Thus it will be the same for all commits during one day. The displayed version will differ as it contains the hash for nightly and build-on-push versions.

It can be decided now whether we set the 'branch_number' to 0 or to 5 (reserving lower numbers for all previously released branches).

Please tell me your thoughts and comments on this and whether such change is acceptable to you and I shall take care of it.

If no action is taken, the internal revision numbers will drop by a few (2 or 3 in case of dutchtrains) as there are branches in the repository. Reported revisions from that branch on the other hand will be quite lower (number of commits leading to that commit) with the potential to confuse version checks which rely on these numbers.

Also available in: Atom PDF