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