Over the course of several major and minor versions of the Beamable Unity SDK, the .gitignore that we ship has changed to reflect which files and folders we expect game developers to commit. As a result, and especially if devs have modified it themselves too, the state of .beamable/.gitignore might end up in a state that is not perfectly appropriate for a project that has been upgraded in place across several versions.
Add a section to the upgrade guide, going at least as far back as v4.0, describing what the .gitignore file or files that we ship are supposed to look like for the target version, and how that changed from the last version.
Ideally the instructions should serve two audiences/modes:
- those who have tinkered with their
.gitignore and want to get up to date while also preserving their own changes
- those who do not care about the details and just want their
.gitignore to be accurate to their SDK version
Over the course of several major and minor versions of the Beamable Unity SDK, the
.gitignorethat we ship has changed to reflect which files and folders we expect game developers to commit. As a result, and especially if devs have modified it themselves too, the state of.beamable/.gitignoremight end up in a state that is not perfectly appropriate for a project that has been upgraded in place across several versions.Add a section to the upgrade guide, going at least as far back as v4.0, describing what the
.gitignorefile or files that we ship are supposed to look like for the target version, and how that changed from the last version.Ideally the instructions should serve two audiences/modes:
.gitignoreand want to get up to date while also preserving their own changes.gitignoreto be accurate to their SDK version