Conversation
| type: string | ||
| description: "Android Swift SDK version list (JSON)" | ||
| default: "[\"nightly-main\", \"nightly-6.3\"]" | ||
| default: "[\"nightly-main\", \"nightly-6.3\", \"6.3\"]" |
There was a problem hiding this comment.
Should we remove nightly-6.3 by default? I don't see it adding value for most devs.
There was a problem hiding this comment.
I was following Static Linux precedent:
github-workflows/.github/workflows/swift_package_test.yml
Lines 57 to 60 in 61db691
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Those 6.2 nightlies should have been dropped once 6.2 was tagged or soon after.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
OK, up to you, I will only raise the matter again once the 6.3 nightlies are stopped.
This PR adds 6.3 to the default
android_sdk_versionsfor 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.