Skip to content

RELEASES.md

Latest commit

 

History

History
79 lines (54 loc) · 3.7 KB

RELEASES.md

File metadata and controls

79 lines (54 loc) · 3.7 KB
Raw

Versioning and releases

The ARM64 application uses semantic release versions, monotonically increasing Apple build numbers and matching annotated Git tags. The current source version is 2.1.1, Apple build 807, tagged as v2.1.1 after validation.

Version sources

Value Source Used by
ARM64 release version MARKETING_VERSION in app/AppARM64.xcconfig CFBundleShortVersionString in both ARM64 application schemes.
Apple build number CURRENT_PROJECT_VERSION in the four project build configurations in iSH.xcodeproj/project.pbxproj CFBundleVersion in the same products.
Source tag annotated Git tag v<release version> Revision lookup and release provenance.

app/Project.xcconfig retains the inherited non-ARM64 version. AppARM64.xcconfig overrides it for the main ARM64 app and is included by AppARM64-ffmpeg.xcconfig, so both shared ARM64 schemes receive the same version.

The arm64-openjdk21-prod-* tags identify dated Linux runtime baselines. They are not app release versions. The existing v2.0.0 tag points to the divergent OpenMinis release commit and is retained for provenance; it is not an ancestor of this branch.

Choose the next version

Use semantic versioning for the shipped application:

  • increment the patch component for compatible fixes without a new user-visible capability;
  • increment the minor component for compatible runtime, terminal or integration capabilities;
  • increment the major component for incompatible app, rootfs or embedding changes.

Increment the Apple build number for every uploaded build, including rebuilds of the same release version. Never reuse a build number already uploaded to App Store Connect.

Update the source

  1. Change MARKETING_VERSION in app/AppARM64.xcconfig.
  2. Change every CURRENT_PROJECT_VERSION entry in iSH.xcodeproj/project.pbxproj to the same new integer.
  3. Update the current version in README.md, docs/IOS_APPLICATION.md and this file.
  4. Add a dated report under docs/reports/releases/ only when an archive or distribution run has produced evidence worth retaining.

Verify the fields:

grep -n 'MARKETING_VERSION' app/Project.xcconfig app/AppARM64.xcconfig
grep -n 'CURRENT_PROJECT_VERSION = ' iSH.xcodeproj/project.pbxproj

All project build configurations must print the same build number.

Validate the release commit

On the AArch64 Linux validation host:

CC=clang make build-arm64-linux-all
CC=clang make test-arm64-fcvt-vector
CC=clang make test-arm64-proc-mem-seek
make check-docs
git diff --check
git status --short

Run the runtime and workload gates required by the changed code as described in VALIDATION.md. Package-manager or repository failures must be recorded separately from emulator results.

Linux validation does not establish Xcode, signing or device behaviour. On macOS, build the two ARM64 schemes that will be distributed and smoke-test the exact archive on a physical device. The inherited Fastlane upload lane targets upstream iSH and must not be used without the changes listed in IOS_APPLICATION.md.

Commit and tag

Commit the version, documentation and release evidence together. Push the commit, create an annotated tag on that exact commit, then push the tag:

git push origin master
git tag -a v2.1.1 -m 'ios-linuxkit 2.1.1'
git push origin v2.1.1

Replace 2.1.1 with the version in app/AppARM64.xcconfig. Verify all three references:

git rev-parse HEAD
git rev-parse origin/master
git rev-list -n 1 v2.1.1
git ls-remote origin refs/heads/master refs/tags/v2.1.1

A Git tag records source provenance. It does not prove that an iOS archive was signed, installed or uploaded.