Skip to content

Android 6.3 support#251

Open
marcprux wants to merge 6 commits intoswiftlang:mainfrom
swift-android-sdk:android-6.3
Open

Android 6.3 support#251
marcprux wants to merge 6 commits intoswiftlang:mainfrom
swift-android-sdk:android-6.3

Conversation

@marcprux
Copy link
Copy Markdown
Contributor

This PR adds 6.3 to the default android_sdk_versions for CI, and also fixes an error with getting the checksum for the final release of the Android SDK in 6.3. This wasn't affecting the earlier nightly-6.3 or nightly-main because their checksum fetching is done in a different place.

@marcprux marcprux requested a review from a team as a code owner March 25, 2026 05:57
type: string
description: "Android Swift SDK version list (JSON)"
default: "[\"nightly-main\", \"nightly-6.3\"]"
default: "[\"nightly-main\", \"nightly-6.3\", \"6.3\"]"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove nightly-6.3 by default? I don't see it adding value for most devs.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following Static Linux precedent:

linux_static_sdk_versions:
type: string
description: "Static Linux Swift SDK version list (JSON)"
default: "[\"nightly-main\", \"nightly-6.2\", \"6.2\"]"

I don't know if it adds value for devs, but it might add value for us so we can more quickly identify any regressions that may come with the 6.3 nightlies.

I can go either way with it. WDYT, @shahmishal?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's even worse: no way static linux SDK users still want the old last 6.2 nightly snapshot built against, a complete waste.

We really need to prune that default version list for all platforms, starting with nightly-6.3 for Android in this pull. The others we can do in another pull, once the reviewers chime in on what they want.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's even worse: no way static linux SDK users still want the old last 6.2 nightly snapshot built against, a complete waste.

Well, I'm guessing that they just haven't updated it for 6.3 yet.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those 6.2 nightlies should have been dropped once 6.2 was tagged or soon after.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, I neglected to mention that there will likely be few 6.3 nightlies going forward, eg there were only a couple dozen 6.2 nightly snapshots after 6.2 was tagged last fall, stopping completely after Dec. 3.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't matter much to me, but each of the other SDKs are tested against each of the three versions: nightly-main, nightly-x.y, and x.y. Are we just concerned about resource utilization? What is the harm of testing against nightly-6.3?

I'm happy to go with whatever @shahmishal and @swiftlang/github-workflows-contributors recommend, but I would like to start testing against 6.3 as soon as possible.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't matter much to me, but each of the other SDKs are tested against each of the three versions: nightly-main, nightly-x.y, and x.y.

That makes perfect sense most of the year, as the two snapshot branches are being actively worked on, and we of course want the current release tested. There is a month or two window each year though, when a new minor release like 6.3 is tagged and the nightly-6.x snapshots for that branch are phased out, where their value is questionable.

Are we just concerned about resource utilization? What is the harm of testing against nightly-6.3?

Yes, wasting resources is the main concern, but not the only one. Right now, we would be testing packages against the 6.3 tag and a 3-week older commit from the same release/6.3 branch, which makes no sense.

How long we keep the 6.3 snapshot branch active as a default is debatable, based on how many new snapshots we expect going forward and how important we think it is to test those, which is why I phrased this originally as a question. If you as the Android release manager don't want to decide, I'm fine with the others you pinged deciding.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, we would be testing packages against the 6.3 tag and a 3-week older commit from the same release/6.3 branch […]

Good point on that, but hopefully we will get some new build soon that surpasses the 6.3 release tag.

My main concern is that we not get blindsided by a regression creeping into 6.3.1, which is what nightly-6.3 will help us exercise once the nightly-6.3 snapshots move forward.

If you as the Android release manager don't want to decide, I'm fine with the others you pinged deciding.

I think it is reasonable to keep Android's default testing matrix consistent with the other SDKs.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, up to you, I will only raise the matter again once the 6.3 nightlies are stopped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants