- Simplify build/version updates by moving MARKETING_VERSION and
CURRENT_PROJECT_VERSION to Config.xcconfig
- Provide Ruby (for fastlane) and Bash (for CI) versions of
xconfig-get/set
- Copy release notes atomically inside the lane to guarantee they are
included in the version commit
- Add -nt to skip the build tag
Simplify development and maintenance immensely by making this a
monorepository:
- Convert PassepartoutKit and VPN bindings to local packages
- OpenVPN/OpenSSL
- WireGuard/Go
- Make PassepartoutKit available via
- Source submodule for production (private)
- [Binary XCFramework for
development](https://github.com/passepartoutvpn/passepartoutkit)
- Add PassepartoutKit Demo in root
- Deploy package later
A tolerant way to cope with scattered approvals. That is, if a
platform build fails to upload, it will not prevent other
platforms from being sent to public_beta/app_review.
The app_store environment is also allowed despite errors, as the
platform builds may have been approved at different times.
This somehow deals with the lottery of getting an approval for
multiple platforms at the same time.
Fixes#1043
Move Core Data tests out of the Library package so that we can still use
the more efficient `swift test` for most tests.
Create a PassepartoutTests target only for tests that require
`xcodebuild`, like Core Data tests.
Eventually:
- PRs only run SwiftPM tests
- Releases run ALL tests with `scan` before `gym`
- Refactor AppUI initialization in all platforms (sort of template
method pattern)
- Make AppMenu specific to macOS by wrapping it into a folder for
consistency
- Add SizeClassProviding for repeated checks on hsClass/vsClass
Fixes#659
Carefully drop the StoreKit and Kvitto dependencies for ProductManager
to be testable.
Rebuild test target completely to start writing meaningful tests in
general.
A bit of everything.
- Use GitHub handles in CHANGELOG
- Mention XOR patch in README and keywords
- Update gems
- Add GitHub issue template
- Fix missing script in release workflow
* Freeze release workflow
- Do not pull anything from master
- Do not push release commit to master
- Only push created version tag
* Refine scripts to start new version
1. Cherry-pick hotfixes from released version
2. Bump version to new version
Normally, 1 is only made of the release commit updating CHANGELOG
with the release date.
However, if a release branch was needed to apply hotfixes to the
latest release, cherry picking will account for the whole release
branch (i.e. multiple commits).
* Ignore more paths for unit testing
