Big Fish SDK Release Notes
Overview
As part of my role at Big Fish Games, I supported release documentation across three SDKs: iOS, Android, and Unity. Each platform used a different versioning scheme, and the SDKs were not in parity, so a single release could require updating up to three separate release notes across three different Docusaurus instances. This sample highlights the published Unity release notes for the Unity SDK.
My Approach
The core challenge was consistency. Release notes varied in structure from platform to platform, and gathering accurate information from engineers was an ad hoc process that differed by team member. I worked closely with engineers to understand new features, bug fixes, and third-party updates, then standardized the format so that release notes across all three SDKs followed the same structure and reading experience, regardless of platform-specific differences.
Implementation
Step 1: Standardize the release notes format
I defined a consistent structure for release notes across all three SDKs. For Unity, this meant leading with two bullets linking to the underlying native platform changes (iOS or Android), followed by the remaining changes organized by severity, and closing with instructions for updating code so that calls would work correctly with the new release.
Step 2: Streamline how information was gathered
To make gathering release notes easier and more reliable, I created a staging notes page in Confluence, where developers on each platform team logged every change made to the SDK since the previous release. Even though the developers just jotted down their notes, this gave me a single, consistent source to pull from instead of chasing updates from multiple engineers across three platforms.
Sample: Staging Release Notes
Staging Release Notes
Instructions: As a developer, it is your responsibility to inform the technical writing team of all changes made to the BFG SDKs. This page is intended as a tool to document the changes that you make to one of the SDKs, along any notes you have about the change.
During testing prior to a release, the technical writing team will use these notes to compose the final version that will be published online. If they have any questions, they will reach out to you individually.
Thank you for your help in streamlining this process!
Non-Released Features, Improvements, or Other Changes
| Date | Contact | Planned Release | Change | Steps a dev needs to take (if needed) |
|---|---|---|---|---|
| Nov 3, 2023 | Ben | Unity 10.6.0 | Upgrade to Unity v2022.3.10 LTS | Unity upgrade has a Gradle update (v7.1.2) in it. Gradle version is updated in the Android Player Settings, in two new gradle files, "baseProjectTemplate.gradle" and "settingsTemplate.gradle". |
| Oct 15, 2023 | Andrew (iOS) Ben (Unity) | iOS 8.4.0 Unity 10.6.0 | Newsletter opt-in New checkbox for all users to opt in; UI updates for new checkbox and policies. | For iOS: Update /Frameworks/ThirdParty/RaveSocial.xcframework and /Frameworks/Resources/BigFishScenePack.bundle. For Unity: Either do iOS steps or replace the entire com.bfg.sdk package |
| Aug 29, 2023 | Tracy | Android 8.6.0 | Update Facebook SDK to v16.2.0 | First, they need to update the facebook-android-sdk version in the project's gradle file, then add the Facebook Client Token to your app’s strings.xml and AndroidManifest.xml files, which is required by Facebook for v13 and above. The next step is to add facebook_app_id and facebook_client_token to your Strings.xml file and add the string entries to the project's manifest file, AndroidManifest.xml I think each of these steps should have sample code, so reach out when you're ready to finalize the notes. No Unity changes needed. |
Published Release Notes
| Release Date | Release Version(s) |
|---|---|
| Sept 26, 2023 | iOS v8.3.0 Android v8.5.0 Unity v10.5.0 |
| June 23, 2023 | iOS v8.3.0 Android v8.4.0 Unity v10.4.0 |
Step 3: Produce the release notes
Using the staging notes as a source, I turned raw developer input into consistent, clear release notes for each SDK, matching the standardized format across all three platforms. The release notes use the same docs-as-code workflow as The Anchor: the new release pages are written in Markdown, the config files for Docusaurus were updated for versioning, and the entire site was built, updated, and published through GitHub Actions.
Once the release documentation was published alongside the release artifacts, I removed all staging notes related to the release. Then, the new release was adding to a second table at the bottom of the page of all published release notes.
Back to Portfolio