about forks and binaries:
* it is unclear whether "release" is meant like "stable release" (every few months) or "nightly release" (every few days)
* suggestion
** all forks get two build jobs
*** build once per day for all platforms, if any vcs changes
**** triggered similar to current "nightly"
**** build for all platforms form current "release"
*** build once per hour for linux64/win64, if any vcs changes
**** similar to current "testing", but triggered at most once per hours, not per commit or push
** there is only one pipeline for all builds of all forks
*** "testing" is skipped if "nightly" is active
*** "testing" is skipped if previous "testing" is still active
*** this distributes limited cpu time most reasonable across all forks
** for pull requests there is little point in building binaries, is there? possibly do the "testing" thing to check platform compatiblity

about fast-forward merges:
* the intention seems to be to review pull requests
* this implies that history is rewritten and rebased all the time
* forcing fast-forward only seems to add no restriction then

plan:
* C1: rework version detection in the source, throw out stuff that uses the linear svn revision to decide compatibility (newgrf version, bananas version)
* C2: move code to git
* C3: change multiplayer compatibility checks to use git hashes (possibly already supported?)
* J: make savegame versions less linear, so there is better inter-operability of savegames between forks. possibly jgr already has something like this