geemili
/
SDL
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
SDL/docs/release_checklist.md

91 lines
2.5 KiB
Markdown
Raw Normal View History

docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
# Release checklist
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
## New feature release
docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
* Update `WhatsNew.txt`
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
* Bump version number to 2.EVEN.0 in all these locations:
docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
* `configure.ac`, `CMakeLists.txt`: `SDL_*_VERSION`
* `Xcode/SDL/Info-Framework.plist`: `CFBundleShortVersionString`,
`CFBundleVersion`
* `Makefile.os2`: `VERSION`
Added instructions for updating Makefile.w32 for release
2022-06-16 13:42:45 -06:00
* `Makefile.w32`: `*_VERSION`
docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
* `include/SDL_version.h`: `SDL_*_VERSION`, `SDL_PATCHLEVEL`
* `src/main/windows/version.rc`: `FILEVERSION`, `PRODUCTVERSION`,
`FileVersion`, `ProductVersion`
* Bump ABI version information
Note that the Xcode DYLIB_COMPATIBILITY_VERSION should always match DYLIB_CURRENT_VERSION CMake doesn't need any special handling
2022-09-05 09:48:16 -06:00
* `Xcode/SDL/SDL.xcodeproj/project.pbxproj`:
build: Mechanically generate ABI versions from version number If we're strict about applying something resembling semantic versioning to the "marketing" version number, then we can mechanically generate the ABI version from it. This limits the range of valid micro versions (patchlevels) to 0-99. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:40:11 -06:00
`DYLIB_CURRENT_VERSION`, `DYLIB_COMPATIBILITY_VERSION`
* set first number in `DYLIB_CURRENT_VERSION` to
(100 * *minor*) + 1
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
* set second number in `DYLIB_CURRENT_VERSION` to 0
Set DYLIB_COMPATIBILITY_VERSION to DYLIB_CURRENT_VERSION to match autotools Autotools sets both versions to the same value, so Xcode and CMake need to match for the libraries to be compatible between the different builds. See these for details: https://github.com/libsdl-org/sdl12-compat/pull/207 https://github.com/libsdl-org/SDL/issues/2934 https://stackoverflow.com/questions/67055770/usage-of-current-version-and-compatibility-version-on-macos
2022-09-05 09:28:06 -06:00
* set `DYLIB_COMPATIBILITY_VERSION` to the same value
docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
workflows: Add a test to assert that all the version numbers agree Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:43:59 -06:00
* Run test/versioning.sh to verify that everything is consistent
docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
* Regenerate `configure`
* Do the release
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
## New bugfix release
* Check that no new API/ABI was added
* If it was, do a new feature release (see above) instead
* Bump version number from 2.Y.Z to 2.Y.(Z+1) (Y is even)
* Same places as listed above
* Bump ABI version information
Note that the Xcode DYLIB_COMPATIBILITY_VERSION should always match DYLIB_CURRENT_VERSION CMake doesn't need any special handling
2022-09-05 09:48:16 -06:00
* `Xcode/SDL/SDL.xcodeproj/project.pbxproj`:
build: Mechanically generate ABI versions from version number If we're strict about applying something resembling semantic versioning to the "marketing" version number, then we can mechanically generate the ABI version from it. This limits the range of valid micro versions (patchlevels) to 0-99. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:40:11 -06:00
`DYLIB_CURRENT_VERSION`, `DYLIB_COMPATIBILITY_VERSION`
* set second number in `DYLIB_CURRENT_VERSION` to *patchlevel*
Note that the Xcode DYLIB_COMPATIBILITY_VERSION should always match DYLIB_CURRENT_VERSION CMake doesn't need any special handling
2022-09-05 09:48:16 -06:00
* set `DYLIB_COMPATIBILITY_VERSION` to the same value
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
workflows: Add a test to assert that all the version numbers agree Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:43:59 -06:00
* Run test/versioning.sh to verify that everything is consistent
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
* Regenerate `configure`
* Do the release
## After a feature release
* Create a branch like `release-2.24.x`
* Bump version number to 2.ODD.0 for next development branch
* Same places as listed above
* Bump ABI version information
* Same places as listed above
* Assume that the next feature release will contain new API/ABI
workflows: Add a test to assert that all the version numbers agree Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:43:59 -06:00
* Run test/versioning.sh to verify that everything is consistent
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
## New development prerelease
* Bump version number from 2.Y.Z to 2.Y.(Z+1) (Y is odd)
docs/release_checklist.md: Document how/where to bump version numbers Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 07:09:12 -06:00
* Same places as listed above
* Bump ABI version information
Note that the Xcode DYLIB_COMPATIBILITY_VERSION should always match DYLIB_CURRENT_VERSION CMake doesn't need any special handling
2022-09-05 09:48:16 -06:00
* `Xcode/SDL/SDL.xcodeproj/project.pbxproj`:
build: Mechanically generate ABI versions from version number If we're strict about applying something resembling semantic versioning to the "marketing" version number, then we can mechanically generate the ABI version from it. This limits the range of valid micro versions (patchlevels) to 0-99. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:40:11 -06:00
`DYLIB_CURRENT_VERSION`, `DYLIB_COMPATIBILITY_VERSION`
* set first number in `DYLIB_CURRENT_VERSION` to
(100 * *minor*) + *patchlevel* + 1
* set second number in `DYLIB_CURRENT_VERSION` to 0
Note that the Xcode DYLIB_COMPATIBILITY_VERSION should always match DYLIB_CURRENT_VERSION CMake doesn't need any special handling
2022-09-05 09:48:16 -06:00
* set `DYLIB_COMPATIBILITY_VERSION` to the same value
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
workflows: Add a test to assert that all the version numbers agree Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-04 09:43:59 -06:00
* Run test/versioning.sh to verify that everything is consistent
Switch versioning scheme to be the same as GLib and Flatpak For stable releases, this gives us the ability to make bugfix-only point releases such as 2.24.1 if we want to, and distinguish between them programmatically. For example, this ability could have been useful after 2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop regressions. For development releases, this gives us the ability to make multiple prereleases during the same feature cycle, and distinguish between them programmatically. For example, this would have been useful during 2.0.22 development, which went through three prereleases before reaching the final release. Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-05-03 08:16:11 -06:00
* Regenerate `configure`
* Do the release